From ameetranjan at gmail.com Mon Dec 1 01:17:02 2014 From: ameetranjan at gmail.com (Amit Ranjan) Date: Sun, 30 Nov 2014 23:17:02 -0700 (MST) Subject: [aerogear-dev] Unable to resolve realm public key remotely In-Reply-To: <20141128140011.GA80824@abstractj.org> References: <1417080090462-10134.post@n5.nabble.com> <1417081974138-10136.post@n5.nabble.com> <1417083773188-10138.post@n5.nabble.com> <1417084118889-10139.post@n5.nabble.com> <20141128140011.GA80824@abstractj.org> Message-ID: <1417414622202-10169.post@n5.nabble.com> Hi Bruno, Thanks for your help. Were you able to reproduce the issue? -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Unable-to-resolve-realm-public-key-remotely-tp10134p10169.html Sent from the aerogear-dev mailing list archive at Nabble.com. From daniel at passos.me Mon Dec 1 07:35:07 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 1 Dec 2014 10:35:07 -0200 Subject: [aerogear-dev] UnifiedPush Server 1.1.0-alpha1 In-Reply-To: References: Message-ID: Hey Matz I'll play a bit with it. btw not sure how important it is, but semver 2.0.0 replaced alpha1 by alpha.1 In related news it's alpha and I think we can ship it to the maven central to the community review. If something is wrong we can always release a new alpha. wdyt? [1] http://semver.org/spec/v2.0.0.html -- Passos On Sat, Nov 29, 2014 at 12:48 PM, Matthias Wessendorf wrote: > Hi, > > this is the first round of the 1.1.x series! It contains new Push networks > (Windows WNS/MPNS) and nice UI enhancements like import/export, as well as > fixes and improvements > > Please test the staged alpha1 release: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4361/ > > > > NOTE: on the 1.0.x series. For December we plan a 1.0.3 release. If needed > we may do a 1.0.4 in 2015, but after the 1.0.3 release is out, I hope to > shift the focus on the 1.1.x series. > > > > > -- > 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/20141201/4639ca2d/attachment.html From matzew at apache.org Mon Dec 1 07:48:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 13:48:50 +0100 Subject: [aerogear-dev] UnifiedPush Server 1.1.0-alpha1 In-Reply-To: References: Message-ID: hey, good point. For second alpha we can go with this versioning (e.g. alpha.2) But this is really not a show-stopper :-) On Mon, Dec 1, 2014 at 1:35 PM, Daniel Passos wrote: > Hey Matz > > I'll play a bit with it. btw not sure how important it is, but semver > 2.0.0 replaced alpha1 by alpha.1 > > In related news it's alpha and I think we can ship it to the maven central > to the community review. If something is wrong we can always release a new > alpha. wdyt? > > [1] http://semver.org/spec/v2.0.0.html > > -- Passos > > > On Sat, Nov 29, 2014 at 12:48 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> this is the first round of the 1.1.x series! It contains new Push >> networks (Windows WNS/MPNS) and nice UI enhancements like import/export, as >> well as fixes and improvements >> >> Please test the staged alpha1 release: >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4361/ >> >> >> >> NOTE: on the 1.0.x series. For December we plan a 1.0.3 release. If >> needed we may do a 1.0.4 in 2015, but after the 1.0.3 release is out, I >> hope to shift the focus on the 1.1.x series. >> >> >> >> >> -- >> 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/20141201/03aac7dc/attachment.html From crobson at redhat.com Mon Dec 1 07:53:09 2014 From: crobson at redhat.com (Catherine Robson) Date: Mon, 01 Dec 2014 07:53:09 -0500 Subject: [aerogear-dev] Aerogear Website Design In-Reply-To: References: <380258845.154073.1417017253168.JavaMail.zimbra@redhat.com> <2109665629.154409.1417017643692.JavaMail.zimbra@redhat.com> <1253638600.156030.1417018406375.JavaMail.zimbra@redhat.com> <904046218.157588.1417020881718.JavaMail.zimbra@redhat.com> Message-ID: <547C64B5.40700@redhat.com> > Matthias Wessendorf > November 26, 2014 at 12:00 PM > > > On Wed, Nov 26, 2014 at 5:54 PM, Andres Galante > wrote: > > We can take a Lean approach on it. > We can put google search, and see on analtitycs how many users > actually do searches to see if it is worth investing time on that > feature. > > +1 > > I guess, if search is the key feature of the site we are doing it > wrong? :-) Data has generally shown there are two types of people - searchers and browsers. Environment/context can influence this behavior as well - so if you see ONLY searching, not browsing then you're probably doing it wrong. But a healthy split is natural. > > > > ----- Original Message ----- > From: "Matthias Wessendorf" > > To: "AeroGear Developer Mailing List" > > > Sent: Wednesday, November 26, 2014 1:18:55 PM > Subject: Re: [aerogear-dev] Aerogear Website Design > > > > On Wed, Nov 26, 2014 at 5:13 PM, Andres Galante < > agalante at redhat.com > wrote: > > > I though I would be nice to have search, specially on documentation. > > Maybe use Google Custom Search? > > yeah, that's fine with me - not sure if we wanna redirect to > google for search results :) > > > > > > > ----- Original Message ----- > From: "Matthias Wessendorf" < matzew at apache.org > > > To: "AeroGear Developer Mailing List" < > aerogear-dev at lists.jboss.org > > Sent: Wednesday, November 26, 2014 1:06:14 PM > Subject: Re: [aerogear-dev] Aerogear Website Design > > Looks really good (besides the blue ;-P) > > One question, the 'search box' -> do we need it? not sure we want > to implement a search engine :-) > > On Wed, Nov 26, 2014 at 5:00 PM, Andres Galante < > agalante at redhat.com > wrote: > > > Hello, > > Just wanted to tell you that Feedhenry gig I was involved is done > and I will mainly be working on the website during the next days. > > I still need to implement the suggestions Lukas, Matthias and > Bruno made, but if you want to follow the progress I'll be > updating it here (please use Safari or Firefox): > > http://andresgalante.com/aerogearwebsite/ > > I will concentrate first on structure and content changes, then on > styling and colors. > > Feedback is very welcome. Please send as much info, changes and > critics as possible. > > Thanks! > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 > Andres Galante > November 26, 2014 at 11:54 AM > We can take a Lean approach on it. > We can put google search, and see on analtitycs how many users > actually do searches to see if it is worth investing time on that feature. > > > ----- Original Message ----- > From: "Matthias Wessendorf" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, November 26, 2014 1:18:55 PM > Subject: Re: [aerogear-dev] Aerogear Website Design > > > > On Wed, Nov 26, 2014 at 5:13 PM, Andres Galante < agalante at redhat.com > > wrote: > > > I though I would be nice to have search, specially on documentation. > > Maybe use Google Custom Search? > > yeah, that's fine with me - not sure if we wanna redirect to google > for search results :) > > > > > > > ----- Original Message ----- > From: "Matthias Wessendorf" < matzew at apache.org > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Sent: Wednesday, November 26, 2014 1:06:14 PM > Subject: Re: [aerogear-dev] Aerogear Website Design > > Looks really good (besides the blue ;-P) > > One question, the 'search box' -> do we need it? not sure we want to > implement a search engine :-) > > On Wed, Nov 26, 2014 at 5:00 PM, Andres Galante < agalante at redhat.com > > wrote: > > > Hello, > > Just wanted to tell you that Feedhenry gig I was involved is done and > I will mainly be working on the website during the next days. > > I still need to implement the suggestions Lukas, Matthias and Bruno > made, but if you want to follow the progress I'll be updating it here > (please use Safari or Firefox): > > http://andresgalante.com/aerogearwebsite/ > > I will concentrate first on structure and content changes, then on > styling and colors. > > Feedback is very welcome. Please send as much info, changes and > critics as possible. > > Thanks! > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > Matthias Wessendorf > November 26, 2014 at 11:18 AM > > > On Wed, Nov 26, 2014 at 5:13 PM, Andres Galante > wrote: > > I though I would be nice to have search, specially on documentation. > > Maybe use Google Custom Search? > > > yeah, that's fine with me - not sure if we wanna redirect to google > for search results :) > > > > > ----- Original Message ----- > From: "Matthias Wessendorf" > > To: "AeroGear Developer Mailing List" > > > Sent: Wednesday, November 26, 2014 1:06:14 PM > Subject: Re: [aerogear-dev] Aerogear Website Design > > Looks really good (besides the blue ;-P) > > One question, the 'search box' -> do we need it? not sure we want > to implement a search engine :-) > > On Wed, Nov 26, 2014 at 5:00 PM, Andres Galante < > agalante at redhat.com > wrote: > > > Hello, > > Just wanted to tell you that Feedhenry gig I was involved is done > and I will mainly be working on the website during the next days. > > I still need to implement the suggestions Lukas, Matthias and > Bruno made, but if you want to follow the progress I'll be > updating it here (please use Safari or Firefox): > > http://andresgalante.com/aerogearwebsite/ > > I will concentrate first on structure and content changes, then on > styling and colors. > > Feedback is very welcome. Please send as much info, changes and > critics as possible. > > Thanks! > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 > Andres Galante > November 26, 2014 at 11:13 AM > I though I would be nice to have search, specially on documentation. > > Maybe use Google Custom Search? > > > > ----- Original Message ----- > From: "Matthias Wessendorf" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, November 26, 2014 1:06:14 PM > Subject: Re: [aerogear-dev] Aerogear Website Design > > Looks really good (besides the blue ;-P) > > One question, the 'search box' -> do we need it? not sure we want to > implement a search engine :-) > > On Wed, Nov 26, 2014 at 5:00 PM, Andres Galante < agalante at redhat.com > > wrote: > > > Hello, > > Just wanted to tell you that Feedhenry gig I was involved is done and > I will mainly be working on the website during the next days. > > I still need to implement the suggestions Lukas, Matthias and Bruno > made, but if you want to follow the progress I'll be updating it here > (please use Safari or Firefox): > > http://andresgalante.com/aerogearwebsite/ > > I will concentrate first on structure and content changes, then on > styling and colors. > > Feedback is very welcome. Please send as much info, changes and > critics as possible. > > Thanks! > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > Matthias Wessendorf > November 26, 2014 at 11:06 AM > Looks really good (besides the blue ;-P) > > One question, the 'search box' -> do we need it? not sure we want to > implement a search engine :-) > > > > > -- > 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 -- Catherine Robson Product Manager - User Experience Red Hat JBoss Middleware c: 978-944-3825 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141201/3e438259/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1313 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141201/3e438259/attachment-0002.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141201/3e438259/attachment-0003.jpg From qmx at qmx.me Mon Dec 1 08:18:48 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 1 Dec 2014 11:18:48 -0200 Subject: [aerogear-dev] UnifiedPush Server 1.1.0-alpha1 In-Reply-To: References: Message-ID: <20141201131848.GQ1912@darkstar.local> On Mon, Dec 01, 2014 at 01:48:50PM +0100, Matthias Wessendorf wrote: > hey, > > good point. For second alpha we can go with this versioning (e.g. alpha.2) > > But this is really not a show-stopper :-) -1 Unless it's extremely hard to fix the version, I think it would be wise for us to change it before releasing. Wrong version tags lend to improper sorting and other annoyances. -- qmx From corinnekrych at gmail.com Mon Dec 1 08:24:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 1 Dec 2014 14:24:05 +0100 Subject: [aerogear-dev] to use or not to use aerogear-ios-http as agerogear-ios-push dependency? Message-ID: <00E7A7F0-6E4F-4A52-B657-D6E93CCA7F2F@gmail.com> Hello Guys Since AGIOS-255 (Basic/Digest auth for aerogear-ios-http) is under review and will be merged soon, one question that pops up is: shall we use ag-ios-http lib to support push registration in Swift lib (aerogear-ios-push). So far we?ve been using plain NSURLSession to do it as it wasn?t yet ready on http lib. Doing so will remove 2 lines of boiler plate code but will add a dependency (although internal to aerogear). As either ways seem fine for me, I?d like to have your views on it. ++ Corinne From daniel at passos.me Mon Dec 1 08:36:11 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 1 Dec 2014 11:36:11 -0200 Subject: [aerogear-dev] Releasing new parent/bom (0.2.10) In-Reply-To: References: Message-ID: On Maven Central http://search.maven.org/#artifactdetails%7Corg.jboss.aerogear%7Caerogear-bom%7C0.2.10%7Cpom -- Passos On Wed, Nov 26, 2014 at 2:19 PM, Matthias Wessendorf wrote: > I tested w/ Android and UPS; +1 on release to the wild > > Ship it!!!!! > > > > -M > > On Tue, Nov 25, 2014 at 2:02 PM, Daniel Passos wrote: > >> Hi All, >> >> I?d like to run a new release of our parent/bom. >> >> Here is some changes related to newer versions: >> Android land >> >> - Update Android version to the Lollipop >> - Update Google Play Service to 6.1.71 (Now using aar instead of jar) >> - Remove Roboeletric >> - Remove Guava >> - Remove Android support library >> >> Test land >> >> - Bump to Arquillian nondeploying container 0.2.0 >> - Bump to Arquillian Graphene 2.1.0.Alpha1 >> >> Feel free to test it. I have plan to release it next thursday. >> >> The staging repo is here: >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4338/ >> >> ? Passos >> ? >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141201/f95734f6/attachment.html From qmx at qmx.me Mon Dec 1 08:49:26 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 1 Dec 2014 11:49:26 -0200 Subject: [aerogear-dev] AGPUSH-1075 / Automatic DB Migrations Message-ID: <20141201134926.GR1912@darkstar.local> Howdy! I was looking at Erik's PR[1] and was wondering about the implications of automatic DB migrations during app startup. I've got a lot of burns from this in the past, including: - DDL statements being disabled in production - Massive lock on a DB during an accidental restart which triggered the changes to happen - failed migration which ended up with the app having a model mismatch. I love migrations, I'm just throwing this here to make sure we're aware of the potential problems that incur with us running them automagically during app startup. Erik pointed out this shouldn't be a problem for openshift-like deployments, but what about the "enterprise" side of the house? Thoughts? [1]:https://github.com/aerogear/aerogear-unifiedpush-server/pull/448 -- qmx From matzew at apache.org Mon Dec 1 08:58:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 14:58:43 +0100 Subject: [aerogear-dev] to use or not to use aerogear-ios-http as agerogear-ios-push dependency? In-Reply-To: <00E7A7F0-6E4F-4A52-B657-D6E93CCA7F2F@gmail.com> References: <00E7A7F0-6E4F-4A52-B657-D6E93CCA7F2F@gmail.com> Message-ID: On Mon, Dec 1, 2014 at 2:24 PM, Corinne Krych wrote: > Hello Guys > > Since AGIOS-255 (Basic/Digest auth for aerogear-ios-http) is under review > and will be merged soon, one question that pops up is: shall we use > ag-ios-http lib to support push registration in Swift lib > (aerogear-ios-push). So far we?ve been using plain NSURLSession to do it as > it wasn?t yet ready on http lib. > I think there are two sides of it: - eat your own dog food - does it really make sense - looking at the "remove 2 lines, but will add dependency"..... sounds like does not really make sense :) I am fine in keeping it as it is. Thanks for the insights! -M > > Doing so will remove 2 lines of boiler plate code but will add a > dependency (although internal to aerogear). As either ways seem fine for > me, I?d like to have your views on it. > > ++ > 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/20141201/1a45799f/attachment.html From bruno at abstractj.org Mon Dec 1 09:03:20 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 1 Dec 2014 12:03:20 -0200 Subject: [aerogear-dev] Unable to resolve realm public key remotely In-Reply-To: <1417184751354-10162.post@n5.nabble.com> References: <1417080090462-10134.post@n5.nabble.com> <1417081974138-10136.post@n5.nabble.com> <1417083773188-10138.post@n5.nabble.com> <1417084118889-10139.post@n5.nabble.com> <20141128140011.GA80824@abstractj.org> <1417184751354-10162.post@n5.nabble.com> Message-ID: <20141201140320.GA67678@abstractj.org> Thanks Amit, will give a look this week and let you know. On 2014-11-28, Amit Ranjan wrote: > Hi Bruno, > > Thanks. I am uploading the files . > > I have tried both building the code that i downloaded from git: > https://github.com/aerogear/aerogear-unifiedpush-server.git > > and deploying the war files that I downloaded from: > https://github.com/aerogear/aerogear-simplepush-server/zipball/0.12.1 > > Wildfly server: > http://download.jboss.org/wildfly/8.1.0.Final/wildfly-8.1.0.Final.zip > > Thanks for your help. Aerogeardump.rar > > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Unable-to-resolve-realm-public-key-remotely-tp10134p10162.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 bruno at abstractj.org Mon Dec 1 09:10:46 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 1 Dec 2014 12:10:46 -0200 Subject: [aerogear-dev] to use or not to use aerogear-ios-http as agerogear-ios-push dependency? In-Reply-To: <00E7A7F0-6E4F-4A52-B657-D6E93CCA7F2F@gmail.com> References: <00E7A7F0-6E4F-4A52-B657-D6E93CCA7F2F@gmail.com> Message-ID: <20141201141046.GB67678@abstractj.org> On 2014-12-01, Corinne Krych wrote: > Hello Guys > > Since AGIOS-255 (Basic/Digest auth for aerogear-ios-http) is under review and will be merged soon, one question that pops up is: shall we use ag-ios-http lib to support push registration in Swift lib (aerogear-ios-push). So far we?ve been using plain NSURLSession to do it as it wasn?t yet ready on http lib. > > Doing so will remove 2 lines of boiler plate code but will add a dependency (although internal to aerogear). As either ways seem fine for me, I?d like to have your views on it. Is the choice between 2 lines of code versus 1 new dependency. I would vote for leave it as is. If the benefit is more than 2 lines, we can revisit it for the future. > > ++ > Corinne > _______________________________________________ > 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 Dec 1 09:12:36 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 1 Dec 2014 16:12:36 +0200 Subject: [aerogear-dev] to use or not to use aerogear-ios-http as agerogear-ios-push dependency? In-Reply-To: References: <00E7A7F0-6E4F-4A52-B657-D6E93CCA7F2F@gmail.com> Message-ID: <2432DCCA-C84F-48C5-B2A5-A6B4766756C1@gmail.com> On Dec 1, 2014, at 3:58 PM, Matthias Wessendorf wrote: > > > On Mon, Dec 1, 2014 at 2:24 PM, Corinne Krych wrote: > Hello Guys > > Since AGIOS-255 (Basic/Digest auth for aerogear-ios-http) is under review and will be merged soon, one question that pops up is: shall we use ag-ios-http lib to support push registration in Swift lib (aerogear-ios-push). So far we?ve been using plain NSURLSession to do it as it wasn?t yet ready on http lib. > > I think there are two sides of it: > - eat your own dog food > - does it really make sense - looking at the "remove 2 lines, but will add dependency"..... sounds like does not really make sense :) > > I am fine in keeping it as it is. +1 the lesser dependencies the better, in cases where it makes sense like here I guess. - Christos > > Thanks for the insights! > > -M > > > > Doing so will remove 2 lines of boiler plate code but will add a dependency (although internal to aerogear). As either ways seem fine for me, I?d like to have your views on it. > > ++ > 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/20141201/e835b33c/attachment.html From bruno at abstractj.org Mon Dec 1 09:12:54 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 1 Dec 2014 12:12:54 -0200 Subject: [aerogear-dev] AGPUSH-1075 / Automatic DB Migrations In-Reply-To: <20141201134926.GR1912@darkstar.local> References: <20141201134926.GR1912@darkstar.local> Message-ID: <20141201141254.GC67678@abstractj.org> Fair enough. I think it should be optional which makes me think about a configuration page for UPS. On 2014-12-01, Douglas Campos wrote: > Howdy! > > I was looking at Erik's PR[1] and was wondering about the implications > of automatic DB migrations during app startup. I've got a lot of burns > from this in the past, including: > > - DDL statements being disabled in production > - Massive lock on a DB during an accidental restart which triggered the > changes to happen > - failed migration which ended up with the app having a model mismatch. > > I love migrations, I'm just throwing this here to make sure we're aware > of the potential problems that incur with us running them automagically > during app startup. > > Erik pointed out this shouldn't be a problem for openshift-like > deployments, but what about the "enterprise" side of the house? > > Thoughts? > > [1]:https://github.com/aerogear/aerogear-unifiedpush-server/pull/448 > > -- > 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 Mon Dec 1 09:13:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 15:13:21 +0100 Subject: [aerogear-dev] UnifiedPush Server 1.1.0-alpha1 In-Reply-To: <20141201131848.GQ1912@darkstar.local> References: <20141201131848.GQ1912@darkstar.local> Message-ID: Ok, I will do that. I actually found a bug :-) https://github.com/aerogear/aerogear-unifiedpush-server/commit/c085ecca3 On Mon, Dec 1, 2014 at 2:18 PM, Douglas Campos wrote: > On Mon, Dec 01, 2014 at 01:48:50PM +0100, Matthias Wessendorf wrote: > > hey, > > > > good point. For second alpha we can go with this versioning (e.g. > alpha.2) > > > > But this is really not a show-stopper :-) > -1 > > Unless it's extremely hard to fix the version, I think it would be wise > for us to change it before releasing. Wrong version tags lend to > improper sorting and other annoyances. > > -- > 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/20141201/206a0b9a/attachment.html From corinnekrych at gmail.com Mon Dec 1 09:14:53 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 1 Dec 2014 15:14:53 +0100 Subject: [aerogear-dev] to use or not to use aerogear-ios-http as agerogear-ios-push dependency? In-Reply-To: <2432DCCA-C84F-48C5-B2A5-A6B4766756C1@gmail.com> References: <00E7A7F0-6E4F-4A52-B657-D6E93CCA7F2F@gmail.com> <2432DCCA-C84F-48C5-B2A5-A6B4766756C1@gmail.com> Message-ID: <7BEB8494-C285-459E-B88C-17225EA833BC@gmail.com> > On 01 Dec 2014, at 15:12, Christos Vasilakis wrote: > > > On Dec 1, 2014, at 3:58 PM, Matthias Wessendorf wrote: > >> >> >> On Mon, Dec 1, 2014 at 2:24 PM, Corinne Krych wrote: >> Hello Guys >> >> Since AGIOS-255 (Basic/Digest auth for aerogear-ios-http) is under review and will be merged soon, one question that pops up is: shall we use ag-ios-http lib to support push registration in Swift lib (aerogear-ios-push). So far we?ve been using plain NSURLSession to do it as it wasn?t yet ready on http lib. >> >> I think there are two sides of it: >> - eat your own dog food >> - does it really make sense - looking at the "remove 2 lines, but will add dependency"..... sounds like does not really make sense :) >> >> I am fine in keeping it as it is. > > +1 the lesser dependencies the better, in cases where it makes sense like here I guess. +1 I lean toward the same approach so far basic auth is not much work to deal with foundation layer. > > - > Christos > > >> >> Thanks for the insights! >> >> -M >> >> >> >> Doing so will remove 2 lines of boiler plate code but will add a dependency (although internal to aerogear). As either ways seem fine for me, I?d like to have your views on it. >> >> ++ >> 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 From ameetranjan at gmail.com Mon Dec 1 09:23:14 2014 From: ameetranjan at gmail.com (Amit Ranjan) Date: Mon, 1 Dec 2014 07:23:14 -0700 (MST) Subject: [aerogear-dev] Unable to resolve realm public key remotely In-Reply-To: <20141201140320.GA67678@abstractj.org> References: <1417080090462-10134.post@n5.nabble.com> <1417081974138-10136.post@n5.nabble.com> <1417083773188-10138.post@n5.nabble.com> <1417084118889-10139.post@n5.nabble.com> <20141128140011.GA80824@abstractj.org> <1417184751354-10162.post@n5.nabble.com> <20141201140320.GA67678@abstractj.org> Message-ID: Hi Bruno, Thanks. On Mon, Dec 1, 2014, 19:33 Bruno Oliveira [via aerogear-dev] < ml-node+s1069024n10178h54 at n5.nabble.com> wrote: > Thanks Amit, will give a look this week and let you know. > > On 2014-11-28, Amit Ranjan wrote: > > > Hi Bruno, > > > > Thanks. I am uploading the files . > > > > I have tried both building the code that i downloaded from git: > > https://github.com/aerogear/aerogear-unifiedpush-server.git > > > > and deploying the war files that I downloaded from: > > https://github.com/aerogear/aerogear-simplepush-server/zipball/0.12.1 > > > > Wildfly server: > > http://download.jboss.org/wildfly/8.1.0.Final/wildfly-8.1.0.Final.zip > > > > Thanks for your help. Aerogeardump.rar > > > > > > > > > > > -- > > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Unable-to-resolve-realm-public-key-remotely-tp10134p10162.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 > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > 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/Unable-to-resolve-realm-public-key-remotely-tp10134p10178.html > To unsubscribe from Unable to resolve realm public key remotely, click > here > > . > NAML > > -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Unable-to-resolve-realm-public-key-remotely-tp10134p10184.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/20141201/c159eb64/attachment-0001.html From ivan.gurtler at ahead-itec.com Mon Dec 1 09:28:58 2014 From: ivan.gurtler at ahead-itec.com (=?UTF-8?Q?Ivan_G=C3=BCrtler?=) Date: Mon, 1 Dec 2014 15:28:58 +0100 Subject: [aerogear-dev] aerogear and proxy Message-ID: Hi, I have a question about using proxy on aerogear comunication with GSM/APNS/WNS. Is it possible? Thanks for your help. Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141201/cdc01b3d/attachment.html From matzew at apache.org Mon Dec 1 09:40:26 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 15:40:26 +0100 Subject: [aerogear-dev] aerogear and proxy In-Reply-To: References: Message-ID: you mean running the Unified Push Server behind a proxy? ATM. that is not possible, but we have plans for it, at some point: https://issues.jboss.org/browse/AGPUSH-306 If you want to help on that area, any help is welcome. That said, we had an older PR on this already in the past - to get some ideas https://github.com/aerogear/aerogear-unifiedpush-server/pull/154 -M On Mon, Dec 1, 2014 at 3:28 PM, Ivan G?rtler wrote: > Hi, > I have a question about using proxy on aerogear comunication with > GSM/APNS/WNS. Is it possible? > > Thanks for your help. > > Ivan > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141201/a070778a/attachment.html From matzew at apache.org Mon Dec 1 09:43:26 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 15:43:26 +0100 Subject: [aerogear-dev] UnifiedPush Server 1.1.0-alpha1 In-Reply-To: References: <20141201131848.GQ1912@darkstar.local> Message-ID: here is the new Staging REPO: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4376/ On Mon, Dec 1, 2014 at 3:13 PM, Matthias Wessendorf wrote: > Ok, I will do that. > > I actually found a bug :-) > > https://github.com/aerogear/aerogear-unifiedpush-server/commit/c085ecca3 > > > > On Mon, Dec 1, 2014 at 2:18 PM, Douglas Campos wrote: > >> On Mon, Dec 01, 2014 at 01:48:50PM +0100, Matthias Wessendorf wrote: >> > hey, >> > >> > good point. For second alpha we can go with this versioning (e.g. >> alpha.2) >> > >> > But this is really not a show-stopper :-) >> -1 >> >> Unless it's extremely hard to fix the version, I think it would be wise >> for us to change it before releasing. Wrong version tags lend to >> improper sorting and other annoyances. >> >> -- >> 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 > -- 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/20141201/830e73ca/attachment.html From supittma at redhat.com Mon Dec 1 09:45:03 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 01 Dec 2014 09:45:03 -0500 Subject: [aerogear-dev] [Android] KeyCloak Authenticator In-Reply-To: References: <5416F96F.8030605@redhat.com> <1410794889840.059d9964@Nodemailer> Message-ID: <547C7EEF.3000405@redhat.com> On 11/26/2014 11:24 AM, Matthias Wessendorf wrote: > > > On Mon, Sep 15, 2014 at 5:28 PM, Bruno Oliveira > wrote: > > Amazing Summers! Please turn this list of thing into Jiras if > possible. > > > late reply :-) > > > +1 I really like that - let's make sure we track that with JIRA - this > _IS_ A really cool feature and does add a lot of value for our > OAuth/KC bits! Sure thing, I'll work with passos and abstractj to make something coherent. > > -Matthias > > ? > abstractj > PGP: 0x84DC9914 > > > On Mon, Sep 15, 2014 at 11:36 AM, Summers Pittman > > wrote: > > DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH > LOGIC > AGAIN! > > Over the weekend I tried my hand at writing a Android Account > Authenticator for KeyCloak. This lets Android manage the KeyCloak > account, fetch tokens, provide tokens to other apps etc. KeyCloak > Authenticator let's you drop your keycloak.json file into an > apk and > access your KeyCloak Account with one line of code from any > application > on your Android device. > > Right now this is very much in the "I have an itch needing > scratching" > phase. It doesn't do any robust error handling, hasn't been > testing off > the golden scenario, has no integration with any of the > AeroGear stuff, > etc. Take a moment to watch the Demo and look at the demo > project. > > Video Demo : > https://plus.google.com/103442292643366117394/posts/WSFbdodMsej > > The Demo video uses Android's native account menu to request > from the > authenticator a KeyCloak account. This launches the > authenticator's > activity which will retrieve the credentials for Android and > store > them. When I am back in the settings page and showing off the > stored > account, this is all native Android UI and not part of the > KeyCloak > authenticator. > > When I launch the Demo application this is a separate > application from > the authenticator apk. The Demo project fetches the KeyCloak > account > from Android and gets its auth token. Then it makes a request to > KeyCloak's account service to fetch the user's account data. > > In the demo app there are three lines of code related to auth. > > final Account account = > am.getAccountsByType("org.keycloak.Account")[0]; > String token = am.getAuthToken(account, > "org.keycloak.Account.token", > null, null, null, > null).getResult().getString(AccountManager.KEY_AUTHTOKEN); > > and > > provider.setDefaultHeader("Authorization", "bearer " + token); > > The first two lines fetch the account and token from Android. The > second line attaches the account's auth token to the web > request to the > server. > > So now what? I'll probably use this for my projects/demos > because it > makes my work easier. Right now it doesn't have any connection > to any > of the "official" projects (Again, I wrote this over the > weekend to see > if I could) however it may be quite useful to someone. In the > project's > README I've included a (incomplete) list of things that don't > work. > > wdyt? > > Links : > Project : > https://github.com/secondsun/keycloak-android-authenticator > Video Demo : > https://plus.google.com/103442292643366117394/posts/WSFbdodMsej > Demo Source : > https://github.com/secondsun/keycloak-account-authenticator-demo/ > > > -- > 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 > > > > > -- > 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 -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141201/375025c0/attachment-0001.html From matzew at apache.org Mon Dec 1 09:48:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 15:48:38 +0100 Subject: [aerogear-dev] Updating the parent of aerogear-parent? Message-ID: Hi, we are on JBoss-11 https://github.com/aerogear/aerogear-parent/blob/master/pom.xml#L34 and I was wondering if anything would prevent us from using latest (16) ? -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/20141201/6dce72e4/attachment.html From daniel at passos.me Mon Dec 1 09:50:42 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 1 Dec 2014 12:50:42 -0200 Subject: [aerogear-dev] Updating the parent of aerogear-parent? In-Reply-To: References: Message-ID: Or [11,) -- Passos On Mon, Dec 1, 2014 at 12:48 PM, Matthias Wessendorf wrote: > Hi, > > we are on JBoss-11 > https://github.com/aerogear/aerogear-parent/blob/master/pom.xml#L34 > > and I was wondering if anything would prevent us from using latest (16) ? > > -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/20141201/25f21332/attachment.html From matzew at apache.org Mon Dec 1 09:57:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 15:57:31 +0100 Subject: [aerogear-dev] Updating the parent of aerogear-parent? In-Reply-To: References: Message-ID: On Mon, Dec 1, 2014 at 3:50 PM, Daniel Passos wrote: > Or [11,) > nah nah - that's odd. I think it makes sense to have a specific parent. I would also expect that this does not work (for a number of reasons) -M > > -- Passos > > On Mon, Dec 1, 2014 at 12:48 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> we are on JBoss-11 >> https://github.com/aerogear/aerogear-parent/blob/master/pom.xml#L34 >> >> and I was wondering if anything would prevent us from using latest (16) ? >> >> -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/20141201/c2582210/attachment.html From matzew at apache.org Mon Dec 1 10:00:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 16:00:08 +0100 Subject: [aerogear-dev] Updating the parent of aerogear-parent? In-Reply-To: References: Message-ID: maven++ UnresolvableModelException: The requested version range '[11,)' does not specify an upper bound at org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:221) at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:898) at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:750) :-) On Mon, Dec 1, 2014 at 3:57 PM, Matthias Wessendorf wrote: > > > On Mon, Dec 1, 2014 at 3:50 PM, Daniel Passos wrote: > >> Or [11,) >> > > nah nah - that's odd. I think it makes sense to have a specific parent. > I would also expect that this does not work (for a number of reasons) > > -M > > > >> >> -- Passos >> >> On Mon, Dec 1, 2014 at 12:48 PM, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> we are on JBoss-11 >>> https://github.com/aerogear/aerogear-parent/blob/master/pom.xml#L34 >>> >>> and I was wondering if anything would prevent us from using latest (16) ? >>> >>> -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/20141201/09f1f306/attachment.html From cvasilak at gmail.com Mon Dec 1 10:12:30 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 1 Dec 2014 17:12:30 +0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Ending meeting. Generating minutes. Be patient :) Meeting ended Mon Dec 1 15:10: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-12-01-15.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-01-15.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-01-15.00.log.html On Nov 30, 2014, at 2:28 PM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20141201 > > > _______________________________________________ > 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/20141201/44d76105/attachment.html From supittma at redhat.com Mon Dec 1 10:46:17 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 01 Dec 2014 10:46:17 -0500 Subject: [aerogear-dev] [UPS] Geolocation Support In-Reply-To: References: Message-ID: <547C8D49.4050506@redhat.com> What other companies provide geofencing and what do their APIs look like? I know Google has some stuff for Android buried in Google Play Services. In general I think it might be less big brother if instead of the user reporting their location we add in metadata to filter incoming messages. This will have us sending more metadata but we don't have to worry about what if some bad guy compromises the server and start following his mother-in-law. On 11/27/2014 11:52 AM, Sebastien Blanc wrote: > > Hi Folks ! > > During our last f2f we agreed on adding some geolocation support for > the next UnifiedPush Release (1.1). I would like to start here a > thread to discuss this topic. > > Let's keep in mind : /Crawl, Walk, Run/ > > I would like to start with a concrete proposition and initiate the > discussions from there : > > > Installations > > > Model > Change > > The idea is to add 2 new fields to the |Installation| Object : > > |double longitude; > double latitude; > > | > > These field *should* be optional ! > > > Registration > > When the device registers, along with alias, categories etc ... it > will also be possible to pass a latitude and longitude. > > Later, we will probably offer a endpoint to update these properties. > |PUT /registry/device/{token}| > > > Sender > > > Server > Side > > We need to extend the current sender API to be able to add geolocation > as a criteria. I see that as something like : > > |{ > "message":{ > "alert":"HELLO! > }, > "criteria":{ > "geolocation": > { > "latitude" : 40.2566 > "longitude": 2.36556 > "within" : 5 > "unit" : "Km" // optional, default is Km > } > } > } > > | > > In this example, the Push Notification will be sent only to devices > within a radius of 5 km of the supplied location. > > On the implementation side, I think it make sense to use Hibernate > Search since it has nice support forSpatial queries > . > > > Sender > Client > > The different Sender Clients (Java, Node.js, .net) should be updated > accordingly. > > > Client > SDKs > > In this fisrt iteration, the registration code would to be updated to > include latitude and longitude for : > > * iOS (Including Safari ? ) > * Android ( Including Chrome Apps ?) > * JS UPS-SPS Lib > * Cordova Plugin > * Amazon > * Windows > > Retrieving the current position of the device is not in scope of this > first version, later we could offer some features around that. > > There are some jiras to track these tasks : > https://issues.jboss.org/browse/AGPUSH-828 > > Comments and questions welcome ! > > Sebi > > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141201/9c0809e9/attachment-0001.html From scm.blanc at gmail.com Mon Dec 1 10:56:57 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 1 Dec 2014 16:56:57 +0100 Subject: [aerogear-dev] [UPS] Geolocation Support In-Reply-To: References: Message-ID: On Thu, Nov 27, 2014 at 11:05 PM, Matthias Wessendorf wrote: > Hrm, > > not sure on that hard integration. Originally we thought about something > like: > > 1) write little native libs (Android/iOS) that help to collect long/lat. > 2) combine them with the registration SDK > > If location is enabled/allowed, store the long/lat to _a_ database - not > the database of the existing metadata. So that would be a completely > different REST api hook > > We could even model that as a separate (micro) service. > Yes, after thinking about this over the weekend, I like that :) Some kind of independant server/(micro-service) , a sort of UGS (Unified Geo Server ;) ). It would offer 2 endpoints : - registration / updating of geo data coupled with an "alias" / devicetoken or smt else we have to agree on. - a "search" api that returns the aliases or devicetokens Then the question is, do we want this service to interact directly with the clients/devices ? Or that UPS "talks" with that geoserver and act a bit like a broker ? One benefit of this latest approach is that this geoserver could be in the same KC realm as UPS. > > Currently I am not sure if it's a good idea to blow up the metadata (with > geo data) and doing the same for the sender. > > > > > > On Thu, Nov 27, 2014 at 5:52 PM, Sebastien Blanc > wrote: > >> Hi Folks ! >> >> During our last f2f we agreed on adding some geolocation support for the >> next UnifiedPush Release (1.1). I would like to start here a thread to >> discuss this topic. >> >> Let's keep in mind : *Crawl, Walk, Run* >> >> I would like to start with a concrete proposition and initiate the >> discussions from there : >> >> >> Installations >> Model >> Change >> >> The idea is to add 2 new fields to the Installation Object : >> >> double longitude; >> double latitude; >> >> >> These field *should* be optional ! >> >> Registration >> >> When the device registers, along with alias, categories etc ... it will >> also be possible to pass a latitude and longitude. >> >> Later, we will probably offer a endpoint to update these properties. PUT >> /registry/device/{token} >> >> Sender >> Server >> Side >> >> We need to extend the current sender API to be able to add geolocation as >> a criteria. I see that as something like : >> >> { >> "message":{ >> "alert":"HELLO! >> }, >> "criteria":{ >> "geolocation": >> { >> "latitude" : 40.2566 >> "longitude": 2.36556 >> "within" : 5 >> "unit" : "Km" // optional, default is Km >> } >> } >> } >> >> >> In this example, the Push Notification will be sent only to devices >> within a radius of 5 km of the supplied location. >> >> On the implementation side, I think it make sense to use Hibernate Search >> since it has nice support forSpatial queries >> >> . >> >> Sender >> Client >> >> The different Sender Clients (Java, Node.js, .net) should be updated >> accordingly. >> Client >> SDKs >> >> In this fisrt iteration, the registration code would to be updated to >> include latitude and longitude for : >> >> - iOS (Including Safari ? ) >> - Android ( Including Chrome Apps ?) >> - JS UPS-SPS Lib >> - Cordova Plugin >> - Amazon >> - Windows >> >> Retrieving the current position of the device is not in scope of this >> first version, later we could offer some features around that. >> >> There are some jiras to track these tasks : >> https://issues.jboss.org/browse/AGPUSH-828 >> >> Comments and questions welcome ! >> >> Sebi >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141201/8d1dbef1/attachment.html From scm.blanc at gmail.com Mon Dec 1 10:57:41 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 1 Dec 2014 16:57:41 +0100 Subject: [aerogear-dev] [UPS] Geolocation Support In-Reply-To: <547C8D49.4050506@redhat.com> References: <547C8D49.4050506@redhat.com> Message-ID: On Mon, Dec 1, 2014 at 4:46 PM, Summers Pittman wrote: > What other companies provide geofencing and what do their APIs look like? > I know Google has some stuff for Android buried in Google Play Services. > > In general I think it might be less big brother if instead of the user > reporting their location we add in metadata to filter incoming messages. > This will have us sending more metadata but we don't have to worry about > what if some bad guy compromises the server and start following his > mother-in-law. > Sorry, I'm not sure to understand the alternative you propose. > > > > On 11/27/2014 11:52 AM, Sebastien Blanc wrote: > > Hi Folks ! > > During our last f2f we agreed on adding some geolocation support for the > next UnifiedPush Release (1.1). I would like to start here a thread to > discuss this topic. > > Let's keep in mind : *Crawl, Walk, Run* > > I would like to start with a concrete proposition and initiate the > discussions from there : > > > Installations > Model > Change > > The idea is to add 2 new fields to the Installation Object : > > double longitude; > double latitude; > > > These field *should* be optional ! > > Registration > > When the device registers, along with alias, categories etc ... it will > also be possible to pass a latitude and longitude. > > Later, we will probably offer a endpoint to update these properties. PUT > /registry/device/{token} > > Sender > Server > Side > > We need to extend the current sender API to be able to add geolocation as > a criteria. I see that as something like : > > { > "message":{ > "alert":"HELLO! > }, > "criteria":{ > "geolocation": > { > "latitude" : 40.2566 > "longitude": 2.36556 > "within" : 5 > "unit" : "Km" // optional, default is Km > } > } > } > > > In this example, the Push Notification will be sent only to devices within > a radius of 5 km of the supplied location. > > On the implementation side, I think it make sense to use Hibernate Search > since it has nice support forSpatial queries > > . > > Sender > Client > > The different Sender Clients (Java, Node.js, .net) should be updated > accordingly. > Client > SDKs > > In this fisrt iteration, the registration code would to be updated to > include latitude and longitude for : > > - iOS (Including Safari ? ) > - Android ( Including Chrome Apps ?) > - JS UPS-SPS Lib > - Cordova Plugin > - Amazon > - Windows > > Retrieving the current position of the device is not in scope of this > first version, later we could offer some features around that. > > There are some jiras to track these tasks : > https://issues.jboss.org/browse/AGPUSH-828 > > Comments and questions welcome ! > > Sebi > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://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/20141201/ea143530/attachment-0001.html From matzew at apache.org Mon Dec 1 11:49:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 17:49:03 +0100 Subject: [aerogear-dev] WebPush - register/create-channel Message-ID: Hi, after performing register, I get URIs for my channel/monitor, like: register [streamid:3] ChannelLink: webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/channel, MonitorLink: webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/monitor I wonder why I do have to explictly create the channel? create-channel webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/channel Not sure I get why that is not created on default. When I am not doing the create-channel, an 'application' (e.g. curl or UPS) has no location to send a paylload for the device, right? Can a device have multiple monitoring channels? (e.g. channels per topic, like #Rihanna #ZZtop #ACDC ? Can a device 'un monitor' ? 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/20141201/aeb2484d/attachment.html From cvasilak at gmail.com Mon Dec 1 12:12:44 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 1 Dec 2014 19:12:44 +0200 Subject: [aerogear-dev] UnifiedPush Server 1.1.0-alpha1 In-Reply-To: References: Message-ID: <2EA949B9-46A2-4322-A18C-E5823CB5300A@gmail.com> Hi, tested the alpha.1 release with our iOS hello world and push-quickstarts demos and both worked great. Tested also the new export functionality and have successfully export/import +1 - Christos On Nov 29, 2014, at 4:48 PM, Matthias Wessendorf wrote: > Hi, > > this is the first round of the 1.1.x series! It contains new Push networks (Windows WNS/MPNS) and nice UI enhancements like import/export, as well as fixes and improvements > > Please test the staged alpha1 release: > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4361/ > > > > NOTE: on the 1.0.x series. For December we plan a 1.0.3 release. If needed we may do a 1.0.4 in 2015, but after the 1.0.3 release is out, I hope to shift the focus on the 1.1.x series. > > > > > -- > 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/20141201/d5244719/attachment.html From cvasilak at gmail.com Mon Dec 1 12:21:43 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 1 Dec 2014 19:21:43 +0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Ending meeting. Generating minutes. Be patient :) Meeting ended Mon Dec 1 15:10: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-12-01-15.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-01-15.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-01-15.00.log.html On Nov 30, 2014, at 2:28 PM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20141201 > > > _______________________________________________ > 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/20141201/772ee7b2/attachment.html From ivan.gurtler at ahead-itec.com Mon Dec 1 12:59:10 2014 From: ivan.gurtler at ahead-itec.com (=?UTF-8?Q?Ivan_G=C3=BCrtler?=) Date: Mon, 1 Dec 2014 18:59:10 +0100 Subject: [aerogear-dev] use oracle database In-Reply-To: <1417092766.2700.15.camel@kpiwko-x220> References: <1417092766.2700.15.camel@kpiwko-x220> Message-ID: Problem is with Instalation Table ... object Instalation have "String deviceToken..." and in database it is LONG ... when we try add Instalation to Aerogear ... it threw exception ... when we hardly changed in database LONG to VARCHAR(255) it is ok ... but it is not a solution ... there in no problem with table PushMessageInformation alhough it also contains LONG column When we try in wildfly again it has same problem ... And the worst is that LONG is deprecated in Oracle ... and CLOB should be used *Mgr. Ivan G?rtler* Mobile software developer AHEAD iTec, s.r.o., Botanick? 554/68a, 602 00 Brno (Czech Republic) www.ahead-itec.com | twitter | mobile security solutions 2014-11-27 13:52 GMT+01:00 Karel Piwko : > Hi Ivan, > > I'll have time to check your setup starting next week and I'll try > reproduce the problem. I would appreciate if you can send me exact > commit sha of UnifiedPush you are using as I've noticed that you are > deploying -SNAPSHOT version. It would also help me to know whether you > are able to reproduce the behavior with UPS 1.0.2 tag/release and > detailed sql query log, that can be enabled in persistence.xml. > > Given the exception, I suspect that default Oracle dialect mapping has > changed from Hibernate 4.1 (EAP 6.3.0) to Hibernate 4.3 (WF 9.0.0.A1). > > Thanks, > > Karel > > > On Wed, 2014-11-26 at 17:21 +0100, Ivan G?rtler wrote: > > Hi, > > I tried to use aerogear with oracle database. When I used wildfly it was > > good. > > > > I create module.xml for "ojdbc6-12.1.0.1.jar": > > > > ** > > > > ** > > * * > > * * > > * * > > * * > > * * > > * * > > * * > > * * > > ** > > > > next I create oracle-database-config-wildfly.cli > > > > *# $WILDFLY_HOME/bin/jboss-cli.sh --file=/path/to/this/file.* > > *connect* > > *batch* > > > > *## Add Oracle driver* > > > */subsystem=datasources/jdbc-driver=oracleup:add(driver-name=oracleup,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)* > > > > *## Add UnifiedPush Datasource* > > *data-source add --name=UnifiedPushDS --driver-name=oracleup > > --jndi-name=java:jboss/datasources/UnifiedPushDS > > --connection-url=jdbc:oracle:thin:@localhost:1521:XE > > --user-name=unifiedpush --password=unifiedpush --use-ccm=false > > --max-pool-size=25 --blocking-timeout-wait-millis=5000 --enabled=true* > > > > *run-batch* > > *#:reload* > > > > next I configurate wildfly with this and deploy 2 war files. It was very > > good :) > > > > But when I tried it with EAP 6.3.0 with same "ojdbc6-12.1.0.1.jar", > > module.xml and > > next oracle-database-config.cli > > > > *# $JBOSS_HOME/bin/jboss-cli.sh --file=/path/to/this/file.* > > *connect* > > *batch* > > > > *## Add Oracle driver* > > > */subsystem=datasources/jdbc-driver=oracleup:add(driver-name=oracleup,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)* > > > > *## Add UnifiedPush Datasource* > > *data-source add --name=UnifiedPushDS --driver-name=oracleup > > --jndi-name=java:jboss/datasources/UnifiedPushDS > > --connection-url=jdbc:oracle:thin:@localhost:1521:XE > > --user-name=unifiedpush --password=unifiedpush --use-ccm=false > > --max-pool-size=25 --blocking-timeout-wait-millis=5000* > > *data-source enable --name=UnifiedPushDS* > > > > *run-batch* > > *#:reload* > > > > > > after configurating database and deploying 2 war files (ag-push.war > > specialy for AS7), it started Aerogear administration web UI and I can > > login to web interface. After creating application and variant, I tried > to > > register mobile device in AG with successfull status in mobile device, > but > > without creating instalation in AG and server threw exception (log) > > > > *17:10:06,593 WARN [org.jboss.resteasy.core.ResourceLocator] > > (http-/0.0.0.0:8080-2) Field uriInfo of subresource > > org.keycloak.services.resources.PublicRealmResource will not be injected > > according to spec* > > *17:10:06,594 WARN [org.jboss.resteasy.core.ResourceLocator] > > (http-/0.0.0.0:8080-2) Field request of subresource > > org.keycloak.services.resources.PublicRealmResource will not be injected > > according to spec* > > *17:10:06,594 WARN [org.jboss.resteasy.core.ResourceLocator] > > (http-/0.0.0.0:8080-2) Field response of subresource > > org.keycloak.services.resources.PublicRealmResource will not be injected > > according to spec* > > *17:10:06,671 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] > > (http-/0.0.0.0:8080-1) Found BeanManager at java:comp/BeanManager* > > *17:10:06,698 INFO [org.jboss.resteasy.spi.ResteasyDeployment] > > (http-/0.0.0.0:8080-1) Deploying javax.ws.rs.core.Application: class > > > org.jboss.aerogear.unifiedpush.rest.RestApplication$Proxy$_$$_WeldClientProxy* > > *17:10:07,074 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] > (EJB > > default - 1) SQL Error: 997, SQLState: 42000* > > *17:10:07,074 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] > (EJB > > default - 1) ORA-00997: illegal use of LONG datatype* > > > > *17:10:07,094 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 1) > > JBAS014134: EJB Invocation failed on component > > ClientInstallationServiceImpl for method public abstract void > > > org.jboss.aerogear.unifiedpush.service.ClientInstallationService.addInstallation(org.jboss.aerogear.unifiedpush.api.Variant,org.jboss.aerogear.unifiedpush.api.Installation): > > javax.ejb.EJBException: javax.persistence.PersistenceException: > > org.hibernate.exception.SQLGrammarException: could not extract ResultSet* > > * at > > > org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:274) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:339) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) > > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) > > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182) > > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$1.runInvocation(AsyncFutureInterceptorFactory.java:89) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > [rt.jar:1.7.0_67]* > > * at > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > [rt.jar:1.7.0_67]* > > * at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]* > > * at org.jboss.threads.JBossThread.run(JBossThread.java:122)* > > *Caused by: javax.persistence.PersistenceException: > > org.hibernate.exception.SQLGrammarException: could not extract ResultSet* > > * at > > > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387) > > > [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at > > > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310) > > > [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:277) > > > [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at > > > org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPAInstallationDao.getSingleResultForQuery(JPAInstallationDao.java:199) > > [unifiedpush-model-jpa-1.1.0-SNAPSHOT.jar:]* > > * at > > > org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPAInstallationDao.findInstallationForVariantByDeviceToken(JPAInstallationDao.java:72) > > [unifiedpush-model-jpa-1.1.0-SNAPSHOT.jar:]* > > * at > > > org.jboss.aerogear.unifiedpush.service.impl.ClientInstallationServiceImpl.findInstallationForVariantByDeviceToken(ClientInstallationServiceImpl.java:177) > > [unifiedpush-service-1.1.0-SNAPSHOT.jar:]* > > * at > > > org.jboss.aerogear.unifiedpush.service.impl.ClientInstallationServiceImpl.addInstallation(ClientInstallationServiceImpl.java:51) > > [unifiedpush-service-1.1.0-SNAPSHOT.jar:]* > > * at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > [rt.jar:1.7.0_67]* > > * at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > [rt.jar:1.7.0_67]* > > * at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > [rt.jar:1.7.0_67]* > > * at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_67]* > > * at > > > org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:86) > > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:97) > > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > > [jboss-as-jpa-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:93) > > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) > > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * at > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* > > * at > > > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:272) > > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* > > * ... 25 more* > > *Caused by: org.hibernate.exception.SQLGrammarException: could not > extract > > ResultSet* > > * at > > > org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:82) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at > > > org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at > > > org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:124) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at > > > org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at > > > org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:88) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.loader.Loader.getResultSet(Loader.java:2062) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1859) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1838) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.loader.Loader.doQuery(Loader.java:906) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at > > > org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:348) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.loader.Loader.doList(Loader.java:2550) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.loader.Loader.doList(Loader.java:2536) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2366) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.loader.Loader.list(Loader.java:2361) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:495) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at > > > org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:357) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at > > > org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:198) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1194) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:268) > > > [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * ... 60 more* > > *Caused by: java.sql.SQLSyntaxErrorException: ORA-00997: illegal use of > > LONG datatype* > > > > * at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)* > > * at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)* > > * at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1017)* > > * at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:655)* > > * at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:249)* > > * at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:566)* > > * at > > > oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:215)* > > * at > > > oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:58)* > > * at > > > oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:776)* > > * at > > > oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:897)* > > * at > > > oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1034)* > > * at > > > oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3820)* > > * at > > > oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3867)* > > * at > > > oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1502)* > > * at > > > org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)* > > * at > > > org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:79) > > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* > > * ... 75 more* > > > > I use same ojdbc6-12.1.0.1.jar and same database with wildfly and EAP > ... I > > tried to fix it for a 3 days, but I haven't found solution. > > > > Can you help me with this problem? Thanks. > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.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/20141201/25723efc/attachment-0001.html From ivan.gurtler at ahead-itec.com Mon Dec 1 13:13:59 2014 From: ivan.gurtler at ahead-itec.com (=?UTF-8?Q?Ivan_G=C3=BCrtler?=) Date: Mon, 1 Dec 2014 19:13:59 +0100 Subject: [aerogear-dev] aerogear and proxy In-Reply-To: References: Message-ID: Thank you *Mgr. Ivan G?rtler* Mobile software developer AHEAD iTec, s.r.o., Botanick? 554/68a, 602 00 Brno (Czech Republic) www.ahead-itec.com | twitter | mobile security solutions 2014-12-01 15:40 GMT+01:00 Matthias Wessendorf : > you mean running the Unified Push Server behind a proxy? > > ATM. that is not possible, but we have plans for it, at some point: > https://issues.jboss.org/browse/AGPUSH-306 > > If you want to help on that area, any help is welcome. That said, we had > an older PR on this already in the past - to get some ideas > https://github.com/aerogear/aerogear-unifiedpush-server/pull/154 > > -M > > On Mon, Dec 1, 2014 at 3:28 PM, Ivan G?rtler > wrote: > >> Hi, >> I have a question about using proxy on aerogear comunication with >> GSM/APNS/WNS. Is it possible? >> >> Thanks for your help. >> >> Ivan >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141201/1741843c/attachment.html From matzew at apache.org Mon Dec 1 14:49:46 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 1 Dec 2014 20:49:46 +0100 Subject: [aerogear-dev] use oracle database In-Reply-To: References: <1417092766.2700.15.camel@kpiwko-x220> Message-ID: On Monday, December 1, 2014, Ivan G?rtler wrote: > Problem is with Instalation Table ... object Instalation have "String > deviceToken..." and in database it is LONG ... > weird, because type is string. Is hibernate getting that mapping wrong? > when we try add Instalation to Aerogear ... it threw exception ... when we > hardly changed in database LONG to VARCHAR(255) it is ok ... > you want it a bit larger: https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/resources/META-INF/orm.xml#L44 is that large size the reason for LONG being used? > but it is not a solution ... there in no problem with table > PushMessageInformation alhough it also contains LONG column > When we try in wildfly again it has same problem ... > And the worst is that LONG is deprecated in Oracle ... and CLOB should be > used > > *Mgr. Ivan G?rtler* > Mobile software developer > > AHEAD iTec, s.r.o., Botanick? 554/68a, > 602 00 Brno (Czech Republic) > > www.ahead-itec.com | twitter | mobile > security solutions > > 2014-11-27 13:52 GMT+01:00 Karel Piwko >: > >> Hi Ivan, >> >> I'll have time to check your setup starting next week and I'll try >> reproduce the problem. I would appreciate if you can send me exact >> commit sha of UnifiedPush you are using as I've noticed that you are >> deploying -SNAPSHOT version. It would also help me to know whether you >> are able to reproduce the behavior with UPS 1.0.2 tag/release and >> detailed sql query log, that can be enabled in persistence.xml. >> >> Given the exception, I suspect that default Oracle dialect mapping has >> changed from Hibernate 4.1 (EAP 6.3.0) to Hibernate 4.3 (WF 9.0.0.A1). >> >> Thanks, >> >> Karel >> >> >> On Wed, 2014-11-26 at 17:21 +0100, Ivan G?rtler wrote: >> > Hi, >> > I tried to use aerogear with oracle database. When I used wildfly it was >> > good. >> > >> > I create module.xml for "ojdbc6-12.1.0.1.jar": >> > >> > ** >> > >> > ** >> > * * >> > * * >> > * * >> > * * >> > * * >> > * * >> > * * >> > * * >> > ** >> > >> > next I create oracle-database-config-wildfly.cli >> > >> > *# $WILDFLY_HOME/bin/jboss-cli.sh --file=/path/to/this/file.* >> > *connect* >> > *batch* >> > >> > *## Add Oracle driver* >> > >> */subsystem=datasources/jdbc-driver=oracleup:add(driver-name=oracleup,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)* >> > >> > *## Add UnifiedPush Datasource* >> > *data-source add --name=UnifiedPushDS --driver-name=oracleup >> > --jndi-name=java:jboss/datasources/UnifiedPushDS >> > --connection-url=jdbc:oracle:thin:@localhost:1521:XE >> > --user-name=unifiedpush --password=unifiedpush --use-ccm=false >> > --max-pool-size=25 --blocking-timeout-wait-millis=5000 --enabled=true* >> > >> > *run-batch* >> > *#:reload* >> > >> > next I configurate wildfly with this and deploy 2 war files. It was very >> > good :) >> > >> > But when I tried it with EAP 6.3.0 with same "ojdbc6-12.1.0.1.jar", >> > module.xml and >> > next oracle-database-config.cli >> > >> > *# $JBOSS_HOME/bin/jboss-cli.sh --file=/path/to/this/file.* >> > *connect* >> > *batch* >> > >> > *## Add Oracle driver* >> > >> */subsystem=datasources/jdbc-driver=oracleup:add(driver-name=oracleup,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)* >> > >> > *## Add UnifiedPush Datasource* >> > *data-source add --name=UnifiedPushDS --driver-name=oracleup >> > --jndi-name=java:jboss/datasources/UnifiedPushDS >> > --connection-url=jdbc:oracle:thin:@localhost:1521:XE >> > --user-name=unifiedpush --password=unifiedpush --use-ccm=false >> > --max-pool-size=25 --blocking-timeout-wait-millis=5000* >> > *data-source enable --name=UnifiedPushDS* >> > >> > *run-batch* >> > *#:reload* >> > >> > >> > after configurating database and deploying 2 war files (ag-push.war >> > specialy for AS7), it started Aerogear administration web UI and I can >> > login to web interface. After creating application and variant, I tried >> to >> > register mobile device in AG with successfull status in mobile device, >> but >> > without creating instalation in AG and server threw exception (log) >> > >> > *17:10:06,593 WARN [org.jboss.resteasy.core.ResourceLocator] >> > (http-/0.0.0.0:8080-2) Field uriInfo of subresource >> > org.keycloak.services.resources.PublicRealmResource will not be injected >> > according to spec* >> > *17:10:06,594 WARN [org.jboss.resteasy.core.ResourceLocator] >> > (http-/0.0.0.0:8080-2) Field request of subresource >> > org.keycloak.services.resources.PublicRealmResource will not be injected >> > according to spec* >> > *17:10:06,594 WARN [org.jboss.resteasy.core.ResourceLocator] >> > (http-/0.0.0.0:8080-2) Field response of subresource >> > org.keycloak.services.resources.PublicRealmResource will not be injected >> > according to spec* >> > *17:10:06,671 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] >> > (http-/0.0.0.0:8080-1) Found BeanManager at java:comp/BeanManager* >> > *17:10:06,698 INFO [org.jboss.resteasy.spi.ResteasyDeployment] >> > (http-/0.0.0.0:8080-1) Deploying javax.ws.rs.core.Application: class >> > >> org.jboss.aerogear.unifiedpush.rest.RestApplication$Proxy$_$$_WeldClientProxy* >> > *17:10:07,074 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] >> (EJB >> > default - 1) SQL Error: 997, SQLState: 42000* >> > *17:10:07,074 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] >> (EJB >> > default - 1) ORA-00997: illegal use of LONG datatype* >> > >> > *17:10:07,094 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 1) >> > JBAS014134: EJB Invocation failed on component >> > ClientInstallationServiceImpl for method public abstract void >> > >> org.jboss.aerogear.unifiedpush.service.ClientInstallationService.addInstallation(org.jboss.aerogear.unifiedpush.api.Variant,org.jboss.aerogear.unifiedpush.api.Installation): >> > javax.ejb.EJBException: javax.persistence.PersistenceException: >> > org.hibernate.exception.SQLGrammarException: could not extract >> ResultSet* >> > * at >> > >> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:274) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:339) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) >> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) >> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) >> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182) >> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$1.runInvocation(AsyncFutureInterceptorFactory.java:89) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> > [rt.jar:1.7.0_67]* >> > * at >> > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> > [rt.jar:1.7.0_67]* >> > * at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]* >> > * at org.jboss.threads.JBossThread.run(JBossThread.java:122)* >> > *Caused by: javax.persistence.PersistenceException: >> > org.hibernate.exception.SQLGrammarException: could not extract >> ResultSet* >> > * at >> > >> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387) >> > >> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at >> > >> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310) >> > >> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:277) >> > >> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at >> > >> org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPAInstallationDao.getSingleResultForQuery(JPAInstallationDao.java:199) >> > [unifiedpush-model-jpa-1.1.0-SNAPSHOT.jar:]* >> > * at >> > >> org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPAInstallationDao.findInstallationForVariantByDeviceToken(JPAInstallationDao.java:72) >> > [unifiedpush-model-jpa-1.1.0-SNAPSHOT.jar:]* >> > * at >> > >> org.jboss.aerogear.unifiedpush.service.impl.ClientInstallationServiceImpl.findInstallationForVariantByDeviceToken(ClientInstallationServiceImpl.java:177) >> > [unifiedpush-service-1.1.0-SNAPSHOT.jar:]* >> > * at >> > >> org.jboss.aerogear.unifiedpush.service.impl.ClientInstallationServiceImpl.addInstallation(ClientInstallationServiceImpl.java:51) >> > [unifiedpush-service-1.1.0-SNAPSHOT.jar:]* >> > * at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> > [rt.jar:1.7.0_67]* >> > * at >> > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> > [rt.jar:1.7.0_67]* >> > * at >> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> > [rt.jar:1.7.0_67]* >> > * at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_67]* >> > * at >> > >> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) >> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:86) >> > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:97) >> > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) >> > [jboss-as-jpa-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:93) >> > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) >> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * at >> > >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >> > * at >> > >> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:272) >> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >> > * ... 25 more* >> > *Caused by: org.hibernate.exception.SQLGrammarException: could not >> extract >> > ResultSet* >> > * at >> > >> org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:82) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at >> > >> org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at >> > >> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:124) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at >> > >> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at >> > >> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:88) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.loader.Loader.getResultSet(Loader.java:2062) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1859) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1838) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.loader.Loader.doQuery(Loader.java:906) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at >> > >> org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:348) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.loader.Loader.doList(Loader.java:2550) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.loader.Loader.doList(Loader.java:2536) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2366) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.loader.Loader.list(Loader.java:2361) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:495) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at >> > >> org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:357) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at >> > >> org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:198) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1194) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:268) >> > >> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * ... 60 more* >> > *Caused by: java.sql.SQLSyntaxErrorException: ORA-00997: illegal use of >> > LONG datatype* >> > >> > * at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)* >> > * at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)* >> > * at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1017)* >> > * at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:655)* >> > * at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:249)* >> > * at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:566)* >> > * at >> > >> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:215)* >> > * at >> > >> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:58)* >> > * at >> > >> oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:776)* >> > * at >> > >> oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:897)* >> > * at >> > >> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1034)* >> > * at >> > >> oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3820)* >> > * at >> > >> oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3867)* >> > * at >> > >> oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1502)* >> > * at >> > >> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)* >> > * at >> > >> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:79) >> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >> > * ... 75 more* >> > >> > I use same ojdbc6-12.1.0.1.jar and same database with wildfly and EAP >> ... I >> > tried to fix it for a 3 days, but I haven't found solution. >> > >> > Can you help me with this problem? Thanks. >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> >> > https://lists.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/20141201/e05b68f1/attachment-0001.html From supittma at redhat.com Mon Dec 1 15:03:30 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 01 Dec 2014 15:03:30 -0500 Subject: [aerogear-dev] Android authz module updates Message-ID: <547CC992.40804@redhat.com> Y'all, Abstractj, passos, and myself just hammered out what the future of the authz module is looking like. Meeting notes : http://oksoclap.com/p/VDKl86lNMP Umbrella JIRA here : https://issues.jboss.org/browse/AGDROID-225 Highlights: # 2.0.0 * Shoot and Share will be put into the cookbook as examples of how to use the current libraries to integrate Google, Facebook, Keycloak, etc * KeyCloak Authenticater and its demo will go into the cookbook as examples of how to integrate KeyCloak into Android. ** https://github.com/secondsun/keycloak-android-authenticator ** https://github.com/secondsun/keycloak-account-authenticator-demo # 2.2 * The current WebView based token life cycle will be replaced with an Intent * The AuthzModule will call the native token store instead of our custom service * The AuthzModule will be enhanced to provide support for consuming and emitting token life cycle Intents. (This means it will function like the KeyCloak authenticator currently does) * The KeyCloak authenticator will be refactored to be included as part of these enhanced APIs -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From bsutter at redhat.com Mon Dec 1 15:11:05 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 1 Dec 2014 15:11:05 -0500 Subject: [aerogear-dev] [UPS] Geolocation Support In-Reply-To: References: Message-ID: After a super quick scan, I did not see anything related to the iOS8 background location tracking - it is important that location-based pushes support both: a) a static lat/long (here is my home address, here is my work address) b) a traveling lat/long (here is where I am at right now?and right now?.and now) > On Nov 27, 2014, at 11:52 AM, Sebastien Blanc wrote: > > Hi Folks ! > > During our last f2f we agreed on adding some geolocation support for the next UnifiedPush Release (1.1). I would like to start here a thread to discuss this topic. > > Let's keep in mind : Crawl, Walk, Run > > I would like to start with a concrete proposition and initiate the discussions from there : > > Installations > > Model Change > > The idea is to add 2 new fields to the Installation Object : > > double longitude; > double latitude; > > These field should be optional ! > > Registration > > When the device registers, along with alias, categories etc ... it will also be possible to pass a latitude and longitude. > > Later, we will probably offer a endpoint to update these properties. PUT /registry/device/{token} > > Sender > > Server Side > > We need to extend the current sender API to be able to add geolocation as a criteria. I see that as something like : > > { > "message":{ > "alert":"HELLO! > }, > "criteria":{ > "geolocation": > { > "latitude" : 40.2566 > "longitude": 2.36556 > "within" : 5 > "unit" : "Km" // optional, default is Km > } > } > } > > In this example, the Push Notification will be sent only to devices within a radius of 5 km of the supplied location. > > On the implementation side, I think it make sense to use Hibernate Search since it has nice support forSpatial queries . > > Sender Client > > The different Sender Clients (Java, Node.js, .net) should be updated accordingly. > > Client SDKs > > In this fisrt iteration, the registration code would to be updated to include latitude and longitude for : > > iOS (Including Safari ? ) > Android ( Including Chrome Apps ?) > JS UPS-SPS Lib > Cordova Plugin > Amazon > Windows > Retrieving the current position of the device is not in scope of this first version, later we could offer some features around that. > > There are some jiras to track these tasks : https://issues.jboss.org/browse/AGPUSH-828 > Comments and questions welcome ! > > 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/20141201/a994b2fb/attachment.html From agalante at redhat.com Mon Dec 1 17:10:41 2014 From: agalante at redhat.com (Andres Galante) Date: Mon, 1 Dec 2014 17:10:41 -0500 (EST) Subject: [aerogear-dev] Aerogear Website Design In-Reply-To: <547C64B5.40700@redhat.com> References: <380258845.154073.1417017253168.JavaMail.zimbra@redhat.com> <2109665629.154409.1417017643692.JavaMail.zimbra@redhat.com> <1253638600.156030.1417018406375.JavaMail.zimbra@redhat.com> <904046218.157588.1417020881718.JavaMail.zimbra@redhat.com> <547C64B5.40700@redhat.com> Message-ID: <48170895.317221.1417471841439.JavaMail.zimbra@redhat.com> Hi! Updates on the website: - I have change the structure a bit to accommodate the information we have on the website now. Added links to Roadmap, Guides and Demos under "Docs" tab. Contributors and Team will be under "community" - I have added a part on the homepage to show the platforms. - I will work on styles later this week. For now please review structure, help me see if this structure can support our content. - I've worked today on Home, Features and Get Started, will work tomorrow on docs and community. And later this week on styling, colors and make it look good. - I've started an illustration to use on the homepage main banner. This is a first idea (also not finished, sorry). https://dl.dropboxusercontent.com/u/4371641/test_home.png - About the search, I left it there for now. We can remove it :) Please view it on Safari or Firfox to understand my idea with the header: http://andresgalante.com/aerogearwebsite/index.html Thanks!! ----- Original Message ----- From: "Catherine Robson" To: "AeroGear Developer Mailing List" Sent: Monday, December 1, 2014 9:53:09 AM Subject: Re: [aerogear-dev] Aerogear Website Design Matthias Wessendorf November 26, 2014 at 12:00 PM On Wed, Nov 26, 2014 at 5:54 PM, Andres Galante < agalante at redhat.com > wrote: We can take a Lean approach on it. We can put google search, and see on analtitycs how many users actually do searches to see if it is worth investing time on that feature. +1 I guess, if search is the key feature of the site we are doing it wrong? :-) Data has generally shown there are two types of people - searchers and browsers. Environment/context can influence this behavior as well - so if you see ONLY searching, not browsing then you're probably doing it wrong. But a healthy split is natural. ----- Original Message ----- From: "Matthias Wessendorf" < matzew at apache.org > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Wednesday, November 26, 2014 1:18:55 PM Subject: Re: [aerogear-dev] Aerogear Website Design On Wed, Nov 26, 2014 at 5:13 PM, Andres Galante < agalante at redhat.com > wrote: I though I would be nice to have search, specially on documentation. Maybe use Google Custom Search? yeah, that's fine with me - not sure if we wanna redirect to google for search results :) ----- Original Message ----- From: "Matthias Wessendorf" < matzew at apache.org > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Wednesday, November 26, 2014 1:06:14 PM Subject: Re: [aerogear-dev] Aerogear Website Design Looks really good (besides the blue ;-P) One question, the 'search box' -> do we need it? not sure we want to implement a search engine :-) On Wed, Nov 26, 2014 at 5:00 PM, Andres Galante < agalante at redhat.com > wrote: Hello, Just wanted to tell you that Feedhenry gig I was involved is done and I will mainly be working on the website during the next days. I still need to implement the suggestions Lukas, Matthias and Bruno made, but if you want to follow the progress I'll be updating it here (please use Safari or Firefox): http://andresgalante.com/aerogearwebsite/ I will concentrate first on structure and content changes, then on styling and colors. Feedback is very welcome. Please send as much info, changes and critics as possible. Thanks! _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 Andres Galante November 26, 2014 at 11:54 AM We can take a Lean approach on it. We can put google search, and see on analtitycs how many users actually do searches to see if it is worth investing time on that feature. ----- Original Message ----- From: "Matthias Wessendorf" To: "AeroGear Developer Mailing List" Sent: Wednesday, November 26, 2014 1:18:55 PM Subject: Re: [aerogear-dev] Aerogear Website Design On Wed, Nov 26, 2014 at 5:13 PM, Andres Galante < agalante at redhat.com > wrote: I though I would be nice to have search, specially on documentation. Maybe use Google Custom Search? yeah, that's fine with me - not sure if we wanna redirect to google for search results :) ----- Original Message ----- From: "Matthias Wessendorf" < matzew at apache.org > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Wednesday, November 26, 2014 1:06:14 PM Subject: Re: [aerogear-dev] Aerogear Website Design Looks really good (besides the blue ;-P) One question, the 'search box' -> do we need it? not sure we want to implement a search engine :-) On Wed, Nov 26, 2014 at 5:00 PM, Andres Galante < agalante at redhat.com > wrote: Hello, Just wanted to tell you that Feedhenry gig I was involved is done and I will mainly be working on the website during the next days. I still need to implement the suggestions Lukas, Matthias and Bruno made, but if you want to follow the progress I'll be updating it here (please use Safari or Firefox): http://andresgalante.com/aerogearwebsite/ I will concentrate first on structure and content changes, then on styling and colors. Feedback is very welcome. Please send as much info, changes and critics as possible. Thanks! _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev Matthias Wessendorf November 26, 2014 at 11:18 AM On Wed, Nov 26, 2014 at 5:13 PM, Andres Galante < agalante at redhat.com > wrote: I though I would be nice to have search, specially on documentation. Maybe use Google Custom Search? yeah, that's fine with me - not sure if we wanna redirect to google for search results :) ----- Original Message ----- From: "Matthias Wessendorf" < matzew at apache.org > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Wednesday, November 26, 2014 1:06:14 PM Subject: Re: [aerogear-dev] Aerogear Website Design Looks really good (besides the blue ;-P) One question, the 'search box' -> do we need it? not sure we want to implement a search engine :-) On Wed, Nov 26, 2014 at 5:00 PM, Andres Galante < agalante at redhat.com > wrote: Hello, Just wanted to tell you that Feedhenry gig I was involved is done and I will mainly be working on the website during the next days. I still need to implement the suggestions Lukas, Matthias and Bruno made, but if you want to follow the progress I'll be updating it here (please use Safari or Firefox): http://andresgalante.com/aerogearwebsite/ I will concentrate first on structure and content changes, then on styling and colors. Feedback is very welcome. Please send as much info, changes and critics as possible. Thanks! _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 Andres Galante November 26, 2014 at 11:13 AM I though I would be nice to have search, specially on documentation. Maybe use Google Custom Search? ----- Original Message ----- From: "Matthias Wessendorf" To: "AeroGear Developer Mailing List" Sent: Wednesday, November 26, 2014 1:06:14 PM Subject: Re: [aerogear-dev] Aerogear Website Design Looks really good (besides the blue ;-P) One question, the 'search box' -> do we need it? not sure we want to implement a search engine :-) On Wed, Nov 26, 2014 at 5:00 PM, Andres Galante < agalante at redhat.com > wrote: Hello, Just wanted to tell you that Feedhenry gig I was involved is done and I will mainly be working on the website during the next days. I still need to implement the suggestions Lukas, Matthias and Bruno made, but if you want to follow the progress I'll be updating it here (please use Safari or Firefox): http://andresgalante.com/aerogearwebsite/ I will concentrate first on structure and content changes, then on styling and colors. Feedback is very welcome. Please send as much info, changes and critics as possible. Thanks! _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev Matthias Wessendorf November 26, 2014 at 11:06 AM Looks really good (besides the blue ;-P) One question, the 'search box' -> do we need it? not sure we want to implement a search engine :-) -- 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 -- Catherine Robson Product Manager - User Experience Red Hat JBoss Middleware c: 978-944-3825 _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel.bevenius at gmail.com Tue Dec 2 02:10:35 2014 From: daniel.bevenius at gmail.com (danielbevenius) Date: Tue, 2 Dec 2014 00:10:35 -0700 (MST) Subject: [aerogear-dev] [WebPush] Update In-Reply-To: References: Message-ID: <1417504235589-10206.post@n5.nabble.com> We have been looking into a companion/extension specification for WebPush named webpush-aggregate[1], and wanted to share some information about it. The webpush-aggregate specification allows for the creation of aggregated channels. What this means is that it is possible to have multiple channels that get notified by a single notification request. You can see a demonstration of this in the provided screen cast [2]. We still have additional functionality to add from the webpush-aggregate spec, like handling expiration, updates to the channels in an aggregate etc. [1] http://tools.ietf.org/html/draft-thomson-webpush-aggregate-00 [2] https://drive.google.com/file/d/0B2E1HZ1JnrJfcXdtR09WUmJfU3M/view?usp=sharing -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-WebPush-Update-tp10055p10206.html Sent from the aerogear-dev mailing list archive at Nabble.com. From edewit at redhat.com Tue Dec 2 02:21:39 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 2 Dec 2014 08:21:39 +0100 Subject: [aerogear-dev] Aerogear Website Design In-Reply-To: <48170895.317221.1417471841439.JavaMail.zimbra@redhat.com> References: <380258845.154073.1417017253168.JavaMail.zimbra@redhat.com> <2109665629.154409.1417017643692.JavaMail.zimbra@redhat.com> <1253638600.156030.1417018406375.JavaMail.zimbra@redhat.com> <904046218.157588.1417020881718.JavaMail.zimbra@redhat.com> <547C64B5.40700@redhat.com> <48170895.317221.1417471841439.JavaMail.zimbra@redhat.com> Message-ID: <648973FA-8F69-4824-B180-E7733019F5C5@redhat.com> On 1 Dec,2014, at 23:10 , Andres Galante wrote: > Hi! > > Updates on the website: > > - I have change the structure a bit to accommodate the information we have on the website now. Added links to Roadmap, Guides and Demos under "Docs" tab. Contributors and Team will be under "community" > > - I have added a part on the homepage to show the platforms. > > - I will work on styles later this week. For now please review structure, help me see if this structure can support our content. > > - I've worked today on Home, Features and Get Started, will work tomorrow on docs and community. And later this week on styling, colors and make it look good. Love what you are doing with it, really nice. > > - I've started an illustration to use on the homepage main banner. This is a first idea (also not finished, sorry). > https://dl.dropboxusercontent.com/u/4371641/test_home.png > > - About the search, I left it there for now. We can remove it :) Our site is pretty static now, but I agree with you we can use google for it. > > Please view it on Safari or Firfox to understand my idea with the header: > > http://andresgalante.com/aerogearwebsite/index.html > Just wondering would this be a good time to add windows to the platform lists? From matzew at apache.org Tue Dec 2 02:35:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 2 Dec 2014 08:35:57 +0100 Subject: [aerogear-dev] [WebPush] Update In-Reply-To: <1417504235589-10206.post@n5.nabble.com> References: <1417504235589-10206.post@n5.nabble.com> Message-ID: interesting screencast. Sounds like way better, than SimplePush. Is there a limit how many devices/channels you can aggregate ? On Tue, Dec 2, 2014 at 8:10 AM, danielbevenius wrote: > We have been looking into a companion/extension specification for WebPush > named webpush-aggregate[1], and wanted to share some information about it. > > The webpush-aggregate specification allows for the creation of aggregated > channels. What this means is that it is possible to have multiple channels > that get notified by a single notification request. You can see a > demonstration of this in the provided screen cast [2]. > > We still have additional functionality to add from the webpush-aggregate > spec, like handling expiration, updates to the channels in an aggregate > etc. > > [1] http://tools.ietf.org/html/draft-thomson-webpush-aggregate-00 > [2] > > https://drive.google.com/file/d/0B2E1HZ1JnrJfcXdtR09WUmJfU3M/view?usp=sharing > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-WebPush-Update-tp10055p10206.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/20141202/703f3e8d/attachment.html From daniel.bevenius at gmail.com Tue Dec 2 02:40:32 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 2 Dec 2014 08:40:32 +0100 Subject: [aerogear-dev] WebPush - register/create-channel In-Reply-To: References: Message-ID: >Not sure I get why that is not created on default. When I am not doing the create-channel, an 'application' (e.g. curl or UPS) has no location to send a >payload for the device, right? My understanding is that the device registers not the application, which for example could be a web browser/user agent. It will then create channels for potentially multiple applications. In the case of usage with the Push-API, a service worker would handle the interaction with the WebPush server and hand out channels to applications. It would also be responsible for handling the inbound notifications, and can take different actions depending on the state of the webapp (post it to an open window, store it, show notification). >Can a device have multiple monitoring channels? (e.g. channels per topic, like #Rihanna #ZZtop #ACDC ? Can a device 'un monitor' ? I think that an application would create separate channels for topic it requires. Not sure about unmonitoring. I've not see anything about that (unless I completely missed it) On 1 December 2014 at 17:49, Matthias Wessendorf wrote: > Hi, > > after performing register, I get URIs for my channel/monitor, like: > > > register > [streamid:3] ChannelLink: > webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/channel, MonitorLink: > webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/monitor > > > I wonder why I do have to explictly create the channel? > create-channel webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/channel > > Not sure I get why that is not created on default. When I am not doing the > create-channel, an 'application' (e.g. curl or UPS) has no location to send > a paylload for the device, right? > > > > Can a device have multiple monitoring channels? (e.g. channels per topic, > like #Rihanna #ZZtop #ACDC ? Can a device 'un monitor' ? > > > 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/20141202/352d6c64/attachment.html From daniel.bevenius at gmail.com Tue Dec 2 02:41:31 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 2 Dec 2014 08:41:31 +0100 Subject: [aerogear-dev] [WebPush] Update In-Reply-To: References: <1417504235589-10206.post@n5.nabble.com> Message-ID: >Is there a limit how many devices/channels you can aggregate ? Nothing in the spec that I've seen yet, but perhaps some upper bound would be good to have. On 2 December 2014 at 08:35, Matthias Wessendorf wrote: > interesting screencast. > > Sounds like way better, than SimplePush. Is there a limit how many > devices/channels you can aggregate ? > > > > > On Tue, Dec 2, 2014 at 8:10 AM, danielbevenius > wrote: > >> We have been looking into a companion/extension specification for WebPush >> named webpush-aggregate[1], and wanted to share some information about it. >> >> The webpush-aggregate specification allows for the creation of aggregated >> channels. What this means is that it is possible to have multiple channels >> that get notified by a single notification request. You can see a >> demonstration of this in the provided screen cast [2]. >> >> We still have additional functionality to add from the webpush-aggregate >> spec, like handling expiration, updates to the channels in an aggregate >> etc. >> >> [1] http://tools.ietf.org/html/draft-thomson-webpush-aggregate-00 >> [2] >> >> https://drive.google.com/file/d/0B2E1HZ1JnrJfcXdtR09WUmJfU3M/view?usp=sharing >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-WebPush-Update-tp10055p10206.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/20141202/228125d7/attachment.html From matzew at apache.org Tue Dec 2 02:49:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 2 Dec 2014 08:49:37 +0100 Subject: [aerogear-dev] WebPush - register/create-channel In-Reply-To: References: Message-ID: On Tue, Dec 2, 2014 at 8:40 AM, Daniel Bevenius wrote: > >Not sure I get why that is not created on default. When I am not doing > the create-channel, an 'application' (e.g. curl or UPS) has no location to > send a >payload for the device, right? > My understanding is that the device registers not the application, which > for example could be a web browser/user agent. > right and the URI, returned to the 'user agent' can be stored on your 'application', like UPS. I wonder why I (being a device/user-agent) explicitly have to create that channel. > It will then create channels for potentially multiple applications. > ok, I see that a few extra 'creates' are needed, for multiple channels. But what's the use case of a register without creating a channel? Just simply to monitor on an existing or different channel ? > In the case of usage with the Push-API, a service worker would handle the > interaction with the WebPush server and hand out channels to applications. > It would also be responsible for handling the inbound notifications, and > can take different actions depending on the state of the webapp (post it to > an open window, store it, show notification). > > >Can a device have multiple monitoring channels? (e.g. channels per > topic, like #Rihanna #ZZtop #ACDC ? Can a device 'un monitor' ? > I think that an application would create separate channels for topic it > requires. > Not sure about unmonitoring. I've not see anything about that (unless I > completely missed it) > Not sure, but I think it might be useful to have an unmonitor, to quite the abo of some content, e.g. at some point #Rihanna might get boring :-) Well, sue I can still 'ignore' it in my code of the service-worker, but would be nice if that guy was no longer bothered :) Or am I having a misunderstanding of the concept here ? > > > > > > On 1 December 2014 at 17:49, Matthias Wessendorf > wrote: > >> Hi, >> >> after performing register, I get URIs for my channel/monitor, like: >> >> >> register >> [streamid:3] ChannelLink: >> webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/channel, MonitorLink: >> webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/monitor >> >> >> I wonder why I do have to explictly create the channel? >> create-channel webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/channel >> >> Not sure I get why that is not created on default. When I am not doing >> the create-channel, an 'application' (e.g. curl or UPS) has no location to >> send a paylload for the device, right? >> >> >> >> Can a device have multiple monitoring channels? (e.g. channels per topic, >> like #Rihanna #ZZtop #ACDC ? Can a device 'un monitor' ? >> >> >> 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/20141202/ad4f1954/attachment-0001.html From matzew at apache.org Tue Dec 2 02:51:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 2 Dec 2014 08:51:37 +0100 Subject: [aerogear-dev] [WebPush] Update In-Reply-To: References: <1417504235589-10206.post@n5.nabble.com> Message-ID: On Tue, Dec 2, 2014 at 8:41 AM, Daniel Bevenius wrote: > >Is there a limit how many devices/channels you can aggregate ? > Nothing in the spec that I've seen yet, but perhaps some upper bound would > be good to have. > It would be nice for use-cases like: My "sports app" subscribes to a game from YOUR_TEAM. A gazillion others do the same. One single aggregate channel/endpoint would be cool - because my "Sports backend', would just have to ping that _one_ endpoint for new payloads. With SimplePush, I'd iterate over a gazillion of URLs, performing HTTP_PUT -M > > On 2 December 2014 at 08:35, Matthias Wessendorf > wrote: > >> interesting screencast. >> >> Sounds like way better, than SimplePush. Is there a limit how many >> devices/channels you can aggregate ? >> >> >> >> >> On Tue, Dec 2, 2014 at 8:10 AM, danielbevenius > > wrote: >> >>> We have been looking into a companion/extension specification for WebPush >>> named webpush-aggregate[1], and wanted to share some information about >>> it. >>> >>> The webpush-aggregate specification allows for the creation of aggregated >>> channels. What this means is that it is possible to have multiple >>> channels >>> that get notified by a single notification request. You can see a >>> demonstration of this in the provided screen cast [2]. >>> >>> We still have additional functionality to add from the webpush-aggregate >>> spec, like handling expiration, updates to the channels in an aggregate >>> etc. >>> >>> [1] http://tools.ietf.org/html/draft-thomson-webpush-aggregate-00 >>> [2] >>> >>> https://drive.google.com/file/d/0B2E1HZ1JnrJfcXdtR09WUmJfU3M/view?usp=sharing >>> >>> >>> >>> -- >>> View this message in context: >>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-WebPush-Update-tp10055p10206.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/20141202/8cca0c49/attachment.html From daniel.bevenius at gmail.com Tue Dec 2 03:13:39 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 2 Dec 2014 09:13:39 +0100 Subject: [aerogear-dev] WebPush - register/create-channel In-Reply-To: References: Message-ID: >right and the URI, returned to the 'user agent' can be stored on your 'application', like UPS. No. The WebLink URL of type "push:channel" returned from the registration request is not shared. When an application requests a channel, the device uses the "push:channel" URL to create a new channel for the application. This channel creation request will contain a "Location" header with the URL that the application will share with a backend, enabling it to send notifications. >I wonder why I (being a device/user-agent) explicitly have to create that channel. I think the spec needs to cater for the ability to have a single web browser case where there a service worker serves multiple applications. For a mobil device it might not make sense to have this shared, and in this case the API can hide the registration. From the end users point of view it could be seen as only a register, something like: http://w3c.github.io/push-api/#example >Not sure, but I think it might be useful to have an unmonitor, to quite the abo of some content, e.g. at some point #Rihanna might get boring :-) If that is the case then I think you can delete the channel. Since the "device" is not specific to a single applications (it could be serving multiple) it still need to be monitoring to receive notifications for other channels. >Or am I having a misunderstanding of the concept here ? Well if you are, then it is me doing a bad job at explaining/describing things. I should say that I'm still learning and might not have correct answers for things yet. On 2 December 2014 at 08:49, Matthias Wessendorf wrote: > > > On Tue, Dec 2, 2014 at 8:40 AM, Daniel Bevenius > wrote: > >> >Not sure I get why that is not created on default. When I am not doing >> the create-channel, an 'application' (e.g. curl or UPS) has no location to >> send a >payload for the device, right? >> My understanding is that the device registers not the application, which >> for example could be a web browser/user agent. >> > > right and the URI, returned to the 'user agent' can be stored on your > 'application', like UPS. > > I wonder why I (being a device/user-agent) explicitly have to create that > channel. > > > >> It will then create channels for potentially multiple applications. >> > > ok, I see that a few extra 'creates' are needed, for multiple channels. > But what's the use case of a register without creating a channel? Just > simply to monitor on an existing or different channel ? > > >> In the case of usage with the Push-API, a service worker would handle the >> interaction with the WebPush server and hand out channels to applications. >> It would also be responsible for handling the inbound notifications, and >> can take different actions depending on the state of the webapp (post it to >> an open window, store it, show notification). >> >> >Can a device have multiple monitoring channels? (e.g. channels per >> topic, like #Rihanna #ZZtop #ACDC ? Can a device 'un monitor' ? >> I think that an application would create separate channels for topic it >> requires. >> Not sure about unmonitoring. I've not see anything about that (unless I >> completely missed it) >> > > Not sure, but I think it might be useful to have an unmonitor, to quite > the abo of some content, e.g. at some point #Rihanna might get boring > :-) > Well, sue I can still 'ignore' it in my code of the service-worker, but > would be nice if that guy was no longer bothered :) > > Or am I having a misunderstanding of the concept here ? > > > > >> >> >> >> >> >> On 1 December 2014 at 17:49, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> after performing register, I get URIs for my channel/monitor, like: >>> >>> >>> register >>> [streamid:3] ChannelLink: >>> webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/channel, MonitorLink: >>> webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/monitor >>> >>> >>> I wonder why I do have to explictly create the channel? >>> create-channel webpush/7df2add5-ec4b-42a2-805f-5f8fcf8faa96/channel >>> >>> Not sure I get why that is not created on default. When I am not doing >>> the create-channel, an 'application' (e.g. curl or UPS) has no location to >>> send a paylload for the device, right? >>> >>> >>> >>> Can a device have multiple monitoring channels? (e.g. channels per >>> topic, like #Rihanna #ZZtop #ACDC ? Can a device 'un monitor' ? >>> >>> >>> 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/20141202/7e3c85ce/attachment.html From daniel.bevenius at gmail.com Tue Dec 2 03:23:34 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 2 Dec 2014 09:23:34 +0100 Subject: [aerogear-dev] [WebPush] Update In-Reply-To: References: <1417504235589-10206.post@n5.nabble.com> Message-ID: Yeah, this is a really nice extension I think. On 2 December 2014 at 08:51, Matthias Wessendorf wrote: > > > On Tue, Dec 2, 2014 at 8:41 AM, Daniel Bevenius > wrote: > >> >Is there a limit how many devices/channels you can aggregate ? >> Nothing in the spec that I've seen yet, but perhaps some upper bound >> would be good to have. >> > > It would be nice for use-cases like: > > My "sports app" subscribes to a game from YOUR_TEAM. A gazillion others do > the same. > > One single aggregate channel/endpoint would be cool - because my "Sports > backend', would just have to ping that _one_ endpoint for new payloads. > > With SimplePush, I'd iterate over a gazillion of URLs, performing HTTP_PUT > > -M > > > > >> >> On 2 December 2014 at 08:35, Matthias Wessendorf >> wrote: >> >>> interesting screencast. >>> >>> Sounds like way better, than SimplePush. Is there a limit how many >>> devices/channels you can aggregate ? >>> >>> >>> >>> >>> On Tue, Dec 2, 2014 at 8:10 AM, danielbevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> We have been looking into a companion/extension specification for >>>> WebPush >>>> named webpush-aggregate[1], and wanted to share some information about >>>> it. >>>> >>>> The webpush-aggregate specification allows for the creation of >>>> aggregated >>>> channels. What this means is that it is possible to have multiple >>>> channels >>>> that get notified by a single notification request. You can see a >>>> demonstration of this in the provided screen cast [2]. >>>> >>>> We still have additional functionality to add from the webpush-aggregate >>>> spec, like handling expiration, updates to the channels in an aggregate >>>> etc. >>>> >>>> [1] http://tools.ietf.org/html/draft-thomson-webpush-aggregate-00 >>>> [2] >>>> >>>> https://drive.google.com/file/d/0B2E1HZ1JnrJfcXdtR09WUmJfU3M/view?usp=sharing >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-WebPush-Update-tp10055p10206.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141202/db639c64/attachment-0001.html From scm.blanc at gmail.com Tue Dec 2 04:15:56 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 2 Dec 2014 10:15:56 +0100 Subject: [aerogear-dev] UnifiedPush Server 1.1.0-alpha1 In-Reply-To: <2EA949B9-46A2-4322-A18C-E5823CB5300A@gmail.com> References: <2EA949B9-46A2-4322-A18C-E5823CB5300A@gmail.com> Message-ID: +1 Release the beast ! On Mon, Dec 1, 2014 at 6:12 PM, Christos Vasilakis wrote: > Hi, > > tested the alpha.1 release with our iOS hello world and push-quickstarts > demos and both worked great. Tested also the new export functionality and > have successfully export/import > > +1 > > - > Christos > > > On Nov 29, 2014, at 4:48 PM, Matthias Wessendorf > wrote: > > Hi, > > this is the first round of the 1.1.x series! It contains new Push networks > (Windows WNS/MPNS) and nice UI enhancements like import/export, as well as > fixes and improvements > > Please test the staged alpha1 release: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4361/ > > > > NOTE: on the 1.0.x series. For December we plan a 1.0.3 release. If needed > we may do a 1.0.4 in 2015, but after the 1.0.3 release is out, I hope to > shift the focus on the 1.1.x series. > > > > > -- > 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/20141202/23a37734/attachment.html From ivan.gurtler at ahead-itec.com Tue Dec 2 04:35:53 2014 From: ivan.gurtler at ahead-itec.com (=?UTF-8?Q?Ivan_G=C3=BCrtler?=) Date: Tue, 2 Dec 2014 10:35:53 +0100 Subject: [aerogear-dev] use oracle database In-Reply-To: References: <1417092766.2700.15.camel@kpiwko-x220> Message-ID: We used VARCHAR2 ... but max value is lower than 4K ... yes ... the reason for LONG is large size ... and LONG in oracle have much problems ... e.g. it is imposible use LONG in "where" -> exception *Mgr. Ivan G?rtler* Mobile software developer AHEAD iTec, s.r.o., Botanick? 554/68a, 602 00 Brno (Czech Republic) www.ahead-itec.com | twitter | mobile security solutions 2014-12-01 20:49 GMT+01:00 Matthias Wessendorf : > > > On Monday, December 1, 2014, Ivan G?rtler > wrote: > >> Problem is with Instalation Table ... object Instalation have "String >> deviceToken..." and in database it is LONG ... >> > > weird, because type is string. > Is hibernate getting that mapping wrong? > > > >> when we try add Instalation to Aerogear ... it threw exception ... when >> we hardly changed in database LONG to VARCHAR(255) it is ok ... >> > > you want it a bit larger: > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/resources/META-INF/orm.xml#L44 > > is that large size the reason for LONG being used? > > > >> but it is not a solution ... there in no problem with table >> PushMessageInformation alhough it also contains LONG column >> When we try in wildfly again it has same problem ... >> And the worst is that LONG is deprecated in Oracle ... and CLOB should be >> used >> >> *Mgr. Ivan G?rtler* >> Mobile software developer >> >> AHEAD iTec, s.r.o., Botanick? 554/68a, >> 602 00 Brno (Czech Republic) >> >> www.ahead-itec.com | twitter | >> mobile security solutions >> >> 2014-11-27 13:52 GMT+01:00 Karel Piwko : >> >>> Hi Ivan, >>> >>> I'll have time to check your setup starting next week and I'll try >>> reproduce the problem. I would appreciate if you can send me exact >>> commit sha of UnifiedPush you are using as I've noticed that you are >>> deploying -SNAPSHOT version. It would also help me to know whether you >>> are able to reproduce the behavior with UPS 1.0.2 tag/release and >>> detailed sql query log, that can be enabled in persistence.xml. >>> >>> Given the exception, I suspect that default Oracle dialect mapping has >>> changed from Hibernate 4.1 (EAP 6.3.0) to Hibernate 4.3 (WF 9.0.0.A1). >>> >>> Thanks, >>> >>> Karel >>> >>> >>> On Wed, 2014-11-26 at 17:21 +0100, Ivan G?rtler wrote: >>> > Hi, >>> > I tried to use aerogear with oracle database. When I used wildfly it >>> was >>> > good. >>> > >>> > I create module.xml for "ojdbc6-12.1.0.1.jar": >>> > >>> > ** >>> > >>> > ** >>> > * * >>> > * * >>> > * * >>> > * * >>> > * * >>> > * * >>> > * * >>> > * * >>> > ** >>> > >>> > next I create oracle-database-config-wildfly.cli >>> > >>> > *# $WILDFLY_HOME/bin/jboss-cli.sh --file=/path/to/this/file.* >>> > *connect* >>> > *batch* >>> > >>> > *## Add Oracle driver* >>> > >>> */subsystem=datasources/jdbc-driver=oracleup:add(driver-name=oracleup,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)* >>> > >>> > *## Add UnifiedPush Datasource* >>> > *data-source add --name=UnifiedPushDS --driver-name=oracleup >>> > --jndi-name=java:jboss/datasources/UnifiedPushDS >>> > --connection-url=jdbc:oracle:thin:@localhost:1521:XE >>> > --user-name=unifiedpush --password=unifiedpush --use-ccm=false >>> > --max-pool-size=25 --blocking-timeout-wait-millis=5000 --enabled=true* >>> > >>> > *run-batch* >>> > *#:reload* >>> > >>> > next I configurate wildfly with this and deploy 2 war files. It was >>> very >>> > good :) >>> > >>> > But when I tried it with EAP 6.3.0 with same "ojdbc6-12.1.0.1.jar", >>> > module.xml and >>> > next oracle-database-config.cli >>> > >>> > *# $JBOSS_HOME/bin/jboss-cli.sh --file=/path/to/this/file.* >>> > *connect* >>> > *batch* >>> > >>> > *## Add Oracle driver* >>> > >>> */subsystem=datasources/jdbc-driver=oracleup:add(driver-name=oracleup,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)* >>> > >>> > *## Add UnifiedPush Datasource* >>> > *data-source add --name=UnifiedPushDS --driver-name=oracleup >>> > --jndi-name=java:jboss/datasources/UnifiedPushDS >>> > --connection-url=jdbc:oracle:thin:@localhost:1521:XE >>> > --user-name=unifiedpush --password=unifiedpush --use-ccm=false >>> > --max-pool-size=25 --blocking-timeout-wait-millis=5000* >>> > *data-source enable --name=UnifiedPushDS* >>> > >>> > *run-batch* >>> > *#:reload* >>> > >>> > >>> > after configurating database and deploying 2 war files (ag-push.war >>> > specialy for AS7), it started Aerogear administration web UI and I can >>> > login to web interface. After creating application and variant, I >>> tried to >>> > register mobile device in AG with successfull status in mobile device, >>> but >>> > without creating instalation in AG and server threw exception (log) >>> > >>> > *17:10:06,593 WARN [org.jboss.resteasy.core.ResourceLocator] >>> > (http-/0.0.0.0:8080-2) Field uriInfo of subresource >>> > org.keycloak.services.resources.PublicRealmResource will not be >>> injected >>> > according to spec* >>> > *17:10:06,594 WARN [org.jboss.resteasy.core.ResourceLocator] >>> > (http-/0.0.0.0:8080-2) Field request of subresource >>> > org.keycloak.services.resources.PublicRealmResource will not be >>> injected >>> > according to spec* >>> > *17:10:06,594 WARN [org.jboss.resteasy.core.ResourceLocator] >>> > (http-/0.0.0.0:8080-2) Field response of subresource >>> > org.keycloak.services.resources.PublicRealmResource will not be >>> injected >>> > according to spec* >>> > *17:10:06,671 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] >>> > (http-/0.0.0.0:8080-1) Found BeanManager at java:comp/BeanManager* >>> > *17:10:06,698 INFO [org.jboss.resteasy.spi.ResteasyDeployment] >>> > (http-/0.0.0.0:8080-1) Deploying javax.ws.rs.core.Application: class >>> > >>> org.jboss.aerogear.unifiedpush.rest.RestApplication$Proxy$_$$_WeldClientProxy* >>> > *17:10:07,074 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] >>> (EJB >>> > default - 1) SQL Error: 997, SQLState: 42000* >>> > *17:10:07,074 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] >>> (EJB >>> > default - 1) ORA-00997: illegal use of LONG datatype* >>> > >>> > *17:10:07,094 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 1) >>> > JBAS014134: EJB Invocation failed on component >>> > ClientInstallationServiceImpl for method public abstract void >>> > >>> org.jboss.aerogear.unifiedpush.service.ClientInstallationService.addInstallation(org.jboss.aerogear.unifiedpush.api.Variant,org.jboss.aerogear.unifiedpush.api.Installation): >>> > javax.ejb.EJBException: javax.persistence.PersistenceException: >>> > org.hibernate.exception.SQLGrammarException: could not extract >>> ResultSet* >>> > * at >>> > >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:274) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:339) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) >>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) >>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) >>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182) >>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$1.runInvocation(AsyncFutureInterceptorFactory.java:89) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> > [rt.jar:1.7.0_67]* >>> > * at >>> > >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> > [rt.jar:1.7.0_67]* >>> > * at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]* >>> > * at org.jboss.threads.JBossThread.run(JBossThread.java:122)* >>> > *Caused by: javax.persistence.PersistenceException: >>> > org.hibernate.exception.SQLGrammarException: could not extract >>> ResultSet* >>> > * at >>> > >>> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387) >>> > >>> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> > >>> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310) >>> > >>> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:277) >>> > >>> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPAInstallationDao.getSingleResultForQuery(JPAInstallationDao.java:199) >>> > [unifiedpush-model-jpa-1.1.0-SNAPSHOT.jar:]* >>> > * at >>> > >>> org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPAInstallationDao.findInstallationForVariantByDeviceToken(JPAInstallationDao.java:72) >>> > [unifiedpush-model-jpa-1.1.0-SNAPSHOT.jar:]* >>> > * at >>> > >>> org.jboss.aerogear.unifiedpush.service.impl.ClientInstallationServiceImpl.findInstallationForVariantByDeviceToken(ClientInstallationServiceImpl.java:177) >>> > [unifiedpush-service-1.1.0-SNAPSHOT.jar:]* >>> > * at >>> > >>> org.jboss.aerogear.unifiedpush.service.impl.ClientInstallationServiceImpl.addInstallation(ClientInstallationServiceImpl.java:51) >>> > [unifiedpush-service-1.1.0-SNAPSHOT.jar:]* >>> > * at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> > [rt.jar:1.7.0_67]* >>> > * at >>> > >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> > [rt.jar:1.7.0_67]* >>> > * at >>> > >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> > [rt.jar:1.7.0_67]* >>> > * at java.lang.reflect.Method.invoke(Method.java:606) >>> [rt.jar:1.7.0_67]* >>> > * at >>> > >>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) >>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:86) >>> > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:97) >>> > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) >>> > [jboss-as-jpa-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:93) >>> > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) >>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * at >>> > >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>> > * at >>> > >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:272) >>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>> > * ... 25 more* >>> > *Caused by: org.hibernate.exception.SQLGrammarException: could not >>> extract >>> > ResultSet* >>> > * at >>> > >>> org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:82) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> > >>> org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> > >>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:124) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> > >>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> > >>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:88) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.loader.Loader.getResultSet(Loader.java:2062) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1859) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1838) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.loader.Loader.doQuery(Loader.java:906) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> > >>> org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:348) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.loader.Loader.doList(Loader.java:2550) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.loader.Loader.doList(Loader.java:2536) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2366) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.loader.Loader.list(Loader.java:2361) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:495) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> > >>> org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:357) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at >>> > >>> org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:198) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1194) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:268) >>> > >>> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * ... 60 more* >>> > *Caused by: java.sql.SQLSyntaxErrorException: ORA-00997: illegal use of >>> > LONG datatype* >>> > >>> > * at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)* >>> > * at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)* >>> > * at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1017)* >>> > * at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:655)* >>> > * at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:249)* >>> > * at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:566)* >>> > * at >>> > >>> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:215)* >>> > * at >>> > >>> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:58)* >>> > * at >>> > >>> oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:776)* >>> > * at >>> > >>> oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:897)* >>> > * at >>> > >>> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1034)* >>> > * at >>> > >>> oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3820)* >>> > * at >>> > >>> oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3867)* >>> > * at >>> > >>> oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1502)* >>> > * at >>> > >>> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)* >>> > * at >>> > >>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:79) >>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>> > * ... 75 more* >>> > >>> > I use same ojdbc6-12.1.0.1.jar and same database with wildfly and EAP >>> ... I >>> > tried to fix it for a 3 days, but I haven't found solution. >>> > >>> > Can you help me with this problem? Thanks. >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.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/20141202/ef18abed/attachment-0001.html From scm.blanc at gmail.com Tue Dec 2 04:44:31 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 2 Dec 2014 10:44:31 +0100 Subject: [aerogear-dev] [UPS] Geolocation Support In-Reply-To: References: Message-ID: On Mon, Dec 1, 2014 at 9:11 PM, Burr Sutter wrote: > After a super quick scan, I did not see anything related to the iOS8 > background location tracking - > For sure, each lib platform will provide some "extras" but before that we should agreed on a first common/unified API set accross the platforms > it is important that location-based pushes support both: > a) a static lat/long (here is my home address, here is my work address) > b) a traveling lat/long (here is where I am at right now?and right > now?.and now) > Interesting, this kind of features make it even more obvious to have a complete independant (Unified) Geo Server. > > On Nov 27, 2014, at 11:52 AM, Sebastien Blanc wrote: > > Hi Folks ! > > During our last f2f we agreed on adding some geolocation support for the > next UnifiedPush Release (1.1). I would like to start here a thread to > discuss this topic. > > Let's keep in mind : *Crawl, Walk, Run* > > I would like to start with a concrete proposition and initiate the > discussions from there : > > Installations > Model > Change > > The idea is to add 2 new fields to the Installation Object : > > double longitude; > double latitude; > > > These field *should* be optional ! > > Registration > > When the device registers, along with alias, categories etc ... it will > also be possible to pass a latitude and longitude. > > Later, we will probably offer a endpoint to update these properties. PUT > /registry/device/{token} > Sender > Server > Side > > We need to extend the current sender API to be able to add geolocation as > a criteria. I see that as something like : > > { > "message":{ > "alert":"HELLO! > }, > "criteria":{ > "geolocation": > { > "latitude" : 40.2566 > "longitude": 2.36556 > "within" : 5 > "unit" : "Km" // optional, default is Km > } > } > } > > > In this example, the Push Notification will be sent only to devices within > a radius of 5 km of the supplied location. > > On the implementation side, I think it make sense to use Hibernate Search > since it has nice support forSpatial queries > > . > Sender > Client > > The different Sender Clients (Java, Node.js, .net) should be updated > accordingly. > Client > SDKs > > In this fisrt iteration, the registration code would to be updated to > include latitude and longitude for : > > - iOS (Including Safari ? ) > - Android ( Including Chrome Apps ?) > - JS UPS-SPS Lib > - Cordova Plugin > - Amazon > - Windows > > Retrieving the current position of the device is not in scope of this > first version, later we could offer some features around that. > > There are some jiras to track these tasks : > https://issues.jboss.org/browse/AGPUSH-828 > > Comments and questions welcome ! > > 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/20141202/8f7f7915/attachment.html From matzew at apache.org Tue Dec 2 08:27:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 2 Dec 2014 13:27:07 +0000 Subject: [aerogear-dev] UnifiedPush Server 1.1.0-alpha1 In-Reply-To: References: <2EA949B9-46A2-4322-A18C-E5823CB5300A@gmail.com> Message-ID: alright, thanks for testing guys! On Tue, Dec 2, 2014 at 9:15 AM, Sebastien Blanc wrote: > +1 > Release the beast ! > > On Mon, Dec 1, 2014 at 6:12 PM, Christos Vasilakis > wrote: > >> Hi, >> >> tested the alpha.1 release with our iOS hello world and push-quickstarts >> demos and both worked great. Tested also the new export functionality and >> have successfully export/import >> >> +1 >> >> - >> Christos >> >> >> On Nov 29, 2014, at 4:48 PM, Matthias Wessendorf >> wrote: >> >> Hi, >> >> this is the first round of the 1.1.x series! It contains new Push >> networks (Windows WNS/MPNS) and nice UI enhancements like import/export, as >> well as fixes and improvements >> >> Please test the staged alpha1 release: >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4361/ >> >> >> >> NOTE: on the 1.0.x series. For December we plan a 1.0.3 release. If >> needed we may do a 1.0.4 in 2015, but after the 1.0.3 release is out, I >> hope to shift the focus on the 1.1.x series. >> >> >> >> >> -- >> 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/20141202/b91cf89c/attachment.html From bruno at abstractj.org Tue Dec 2 09:15:08 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 2 Dec 2014 12:15:08 -0200 Subject: [aerogear-dev] Call for arms - deprecating some projects Message-ID: <20141202141508.GA75820@abstractj.org> Good morning, while I was doing some security stuff. I found projects no longer maintained at our organization. I think we should add a deprecation to inform our community that these projects are no longer maintained[1]. I would like your help reviewing which projects are no longer supported on AeroGear[2], otherwise I do it until the end of this week. Thanks in advance. [1] - https://github.com/aerogear/aerogear-security/blob/master/README.md [2] - https://github.com/aerogear -- abstractj PGP: 0x84DC9914 From supittma at redhat.com Tue Dec 2 09:59:16 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 02 Dec 2014 09:59:16 -0500 Subject: [aerogear-dev] [UPS] Geolocation Support In-Reply-To: References: <547C8D49.4050506@redhat.com> Message-ID: <547DD3C4.6010301@redhat.com> On 12/01/2014 10:57 AM, Sebastien Blanc wrote: > > > On Mon, Dec 1, 2014 at 4:46 PM, Summers Pittman > wrote: > > What other companies provide geofencing and what do their APIs > look like? > I know Google has some stuff for Android buried in Google Play > Services. > > In general I think it might be less big brother if instead of the > user reporting their location we add in metadata to filter > incoming messages. This will have us sending more metadata but we > don't have to worry about what if some bad guy compromises the > server and start following his mother-in-law. > > Sorry, I'm not sure to understand the alternative you propose. I don't like the push server knowing every user's location. Instead of the push server deciding to send to a user based on her location the push server should send a "filter" property with the message the client can use to determine if it should show the message. > > > > > On 11/27/2014 11:52 AM, Sebastien Blanc wrote: >> >> Hi Folks ! >> >> During our last f2f we agreed on adding some geolocation support >> for the next UnifiedPush Release (1.1). I would like to start >> here a thread to discuss this topic. >> >> Let's keep in mind : /Crawl, Walk, Run/ >> >> I would like to start with a concrete proposition and initiate >> the discussions from there : >> >> >> Installations >> >> >> Model >> Change >> >> The idea is to add 2 new fields to the |Installation| Object : >> >> |double longitude; >> double latitude; >> >> | >> >> These field *should* be optional ! >> >> >> Registration >> >> When the device registers, along with alias, categories etc ... >> it will also be possible to pass a latitude and longitude. >> >> Later, we will probably offer a endpoint to update these >> properties. |PUT /registry/device/{token}| >> >> >> Sender >> >> >> Server >> Side >> >> We need to extend the current sender API to be able to add >> geolocation as a criteria. I see that as something like : >> >> |{ >> "message":{ >> "alert":"HELLO! >> }, >> "criteria":{ >> "geolocation": >> { >> "latitude" : 40.2566 >> "longitude": 2.36556 >> "within" : 5 >> "unit" : "Km" // optional, default is Km >> } >> } >> } >> >> | >> >> In this example, the Push Notification will be sent only to >> devices within a radius of 5 km of the supplied location. >> >> On the implementation side, I think it make sense to use >> Hibernate Search since it has nice support forSpatial queries >> . >> >> >> Sender >> Client >> >> The different Sender Clients (Java, Node.js, .net) should be >> updated accordingly. >> >> >> Client >> SDKs >> >> In this fisrt iteration, the registration code would to be >> updated to include latitude and longitude for : >> >> * iOS (Including Safari ? ) >> * Android ( Including Chrome Apps ?) >> * JS UPS-SPS Lib >> * Cordova Plugin >> * Amazon >> * Windows >> >> Retrieving the current position of the device is not in scope of >> this first version, later we could offer some features around that. >> >> There are some jiras to track these tasks : >> https://issues.jboss.org/browse/AGPUSH-828 >> >> Comments and questions welcome ! >> >> Sebi >> >> >> >> _______________________________________________ >> 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 -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141202/30faab78/attachment.html From supittma at redhat.com Tue Dec 2 10:00:23 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 02 Dec 2014 10:00:23 -0500 Subject: [aerogear-dev] Call for arms - deprecating some projects In-Reply-To: <20141202141508.GA75820@abstractj.org> References: <20141202141508.GA75820@abstractj.org> Message-ID: <547DD407.90309@redhat.com> On 12/02/2014 09:15 AM, Bruno Oliveira wrote: > Good morning, while I was doing some security stuff. I found > projects no longer maintained at our organization. I think we should add > a deprecation to inform our community that these projects are no longer > maintained[1]. > > I would like your help reviewing which projects are no longer supported > on AeroGear[2], otherwise I do it until the end of this week. Well I know on the Android side of things, the Aerogear-Android repository isn't being kept up as all new development is in the module repositories. > > Thanks in advance. > > > [1] - > https://github.com/aerogear/aerogear-security/blob/master/README.md > [2] - https://github.com/aerogear > > -- > > 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 corinnekrych at gmail.com Tue Dec 2 10:34:09 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 2 Dec 2014 16:34:09 +0100 Subject: [aerogear-dev] Small thought on repos naming Message-ID: <958675CD-7F50-486C-B41C-C200FCDD0B2E@gmail.com> Hello Last June we talked about aligning your repo naming convention, as a result ios repos were renamed: aerogear-ios-LIB_NAME like we have: aerogear-android-LIB_NAME aerogear-js-LIB_NAME Would it make sense to have: aerogear-cordova-LIB_NAME instead of aerogear-LIB_NAME-cordova @edewit wdyt? ++ Corinne PS: we still have some exception (which will need renaming) like aerogear-otp-js but OTP libes are conssitant across platforms though... From agalante at redhat.com Tue Dec 2 10:36:50 2014 From: agalante at redhat.com (Andres Galante) Date: Tue, 2 Dec 2014 10:36:50 -0500 (EST) Subject: [aerogear-dev] Aerogear Website Design In-Reply-To: <648973FA-8F69-4824-B180-E7733019F5C5@redhat.com> References: <380258845.154073.1417017253168.JavaMail.zimbra@redhat.com> <1253638600.156030.1417018406375.JavaMail.zimbra@redhat.com> <904046218.157588.1417020881718.JavaMail.zimbra@redhat.com> <547C64B5.40700@redhat.com> <48170895.317221.1417471841439.JavaMail.zimbra@redhat.com> <648973FA-8F69-4824-B180-E7733019F5C5@redhat.com> Message-ID: <370366896.357610.1417534610821.JavaMail.zimbra@redhat.com> Thanks Erik, I've added Windows. On our current website we have different structures for each platform documentation: Android looks like this: http://aerogear.org/docs/specs/aerogear-android/ iOS like this: http://aerogear.org/docs/specs/aerogear-ios-oauth2/ and others are on the structure of the website. The question is: Can we put everything under the same structure? Will it be too hard to move the docs? At the moment the structure of the docs I am doing looks like this: http://andresgalante.com/aerogearwebsite/docs_home.html What do you think? ----- Original Message ----- From: "Erik Jan de Wit" To: "AeroGear Developer Mailing List" Sent: Tuesday, December 2, 2014 4:21:39 AM Subject: Re: [aerogear-dev] Aerogear Website Design On 1 Dec,2014, at 23:10 , Andres Galante wrote: > Hi! > > Updates on the website: > > - I have change the structure a bit to accommodate the information we have on the website now. Added links to Roadmap, Guides and Demos under "Docs" tab. Contributors and Team will be under "community" > > - I have added a part on the homepage to show the platforms. > > - I will work on styles later this week. For now please review structure, help me see if this structure can support our content. > > - I've worked today on Home, Features and Get Started, will work tomorrow on docs and community. And later this week on styling, colors and make it look good. Love what you are doing with it, really nice. > > - I've started an illustration to use on the homepage main banner. This is a first idea (also not finished, sorry). > https://dl.dropboxusercontent.com/u/4371641/test_home.png > > - About the search, I left it there for now. We can remove it :) Our site is pretty static now, but I agree with you we can use google for it. > > Please view it on Safari or Firfox to understand my idea with the header: > > http://andresgalante.com/aerogearwebsite/index.html > Just wondering would this be a good time to add windows to the platform lists? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Dec 2 11:36:00 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 2 Dec 2014 16:36:00 +0000 Subject: [aerogear-dev] [Unified Push Server] Testing registration of several devices Message-ID: Hi, a few days ago I wrote a little test, that registers some installations in a concurrent fashion against a running UPS. Here is a polished version: https://gist.github.com/matzew/bb2c11bf55e2e5c7334d The RESTful endpoints are behaving fine (they return 200) and deliver internally the tasks to a new thread, using our Async EJB. yay! Of course, on different databases I noticed different results: * POSTGRES With Postgres I got reasonalbe/good results: 16 threads/1000 loops -> unit test took 50 seconds. (16k devices) 32 threads/1000 loops -> unit test took 120 seconds. (32k devices) ==> would be nice if we could improve this (e.g. with better JPQL or something like that) * H2 (WARNING - not a production database) Writing to the H2 DB is (extremely) slow, regardless if in-memory or file-system :) So, when the Unit test was done/finised, the writing to the (H2) database still goes on, for quite some time. Using the H2 filesystem storage, I noticed some of these log messages -> https://gist.github.com/matzew/41635a254cbec9057e77 Sure, it's H2 and we only use that during our development and test execution but I want at least mention the above behavior * MYSQL TBD Oh, another thing I thought about, perhaps it would be possible to use (embedded) Postgress/MySQL during our tests with these guys: * https://github.com/NessComputing/components-ness-pg * mysql-connector-mxj Any thoughts ? -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/20141202/5e590390/attachment.html From matzew at apache.org Tue Dec 2 11:41:40 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 2 Dec 2014 16:41:40 +0000 Subject: [aerogear-dev] [Unified Push Server] Improving the message delivery to GCM Message-ID: Hello! right now, we use HTTP (via Google's Sender), and they only allow 1000 tokens, per request to GCM, that means, we have a lot of (blocking) requests (see below trace). We loop over the our 'processGCM', which internally invokes the HTTP sender from google: https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L118-L129 (they use HttpUrlConnection inside of that 'sender') I see some improvements here: * make the requests to google concurrent * use persistent XMPP connection (https://issues.jboss.org/browse/AGPUSH-36) Regarding AGPUSH-36 we could extract that into a tiny libray, to be used by UPS (like we did with others). Greetings, Matthias {sending some requests to GCM, in a loop with blocking http request} 21:13:00,059 INFO [GCMPushNotificationSender] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:01,568 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:02,646 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:03,495 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:04,291 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:05,171 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:06,054 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:06,982 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:07,846 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:08,748 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:09,662 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:10,527 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:11,384 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:12,253 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:13,349 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:14,283 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:15,164 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:16,004 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:16,796 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:17,620 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:18,407 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:19,158 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:19,942 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:20,696 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:21,587 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:22,388 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:23,055 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:23,763 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:24,490 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:25,351 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:26,125 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:26,857 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:27,545 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:28,208 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:28,865 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:29,523 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:30,299 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:30,973 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:31,588 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:32,196 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:32,796 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:33,404 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:34,174 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:34,799 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:35,354 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:35,893 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:36,449 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:36,991 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM 21:13:37,488 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [10] devices to GCM // yes, I had 48010 devices 21:13:37,525 INFO [ClientInstallationServiceImpl] (EJB default - 2) Message to GCM has been submitted -- 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/20141202/428cd0ce/attachment.html From matzew at apache.org Tue Dec 2 11:45:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 2 Dec 2014 16:45:05 +0000 Subject: [aerogear-dev] [Unified Push Server] Testing registration of several devices In-Reply-To: References: Message-ID: On Tue, Dec 2, 2014 at 4:36 PM, Matthias Wessendorf wrote: > Hi, > > a few days ago I wrote a little test, that registers some installations in > a concurrent fashion against a running UPS. Here is a polished version: > https://gist.github.com/matzew/bb2c11bf55e2e5c7334d > > The RESTful endpoints are behaving fine (they return 200) and deliver > internally the tasks to a new thread, using our Async EJB. yay! > > Of course, on different databases I noticed different results: > > * POSTGRES > With Postgres I got reasonalbe/good results: > 16 threads/1000 loops -> unit test took 50 seconds. (16k devices) > 32 threads/1000 loops -> unit test took 120 seconds. (32k devices) > > ==> would be nice if we could improve this (e.g. with better JPQL or > something like that) > tracking this here: https://issues.jboss.org/browse/AGPUSH-1127 -M > > > * H2 (WARNING - not a production database) > Writing to the H2 DB is (extremely) slow, regardless if in-memory or > file-system :) > So, when the Unit test was done/finised, the writing to the (H2) database > still goes on, for quite some time. > Using the H2 filesystem storage, I noticed some of these log messages -> > https://gist.github.com/matzew/41635a254cbec9057e77 > > Sure, it's H2 and we only use that during our development and test > execution but I want at least mention the above behavior > > * MYSQL > TBD > > Oh, another thing I thought about, perhaps it would be possible to use > (embedded) Postgress/MySQL during our tests with these guys: > * https://github.com/NessComputing/components-ness-pg > * mysql-connector-mxj > > > Any thoughts ? > -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/20141202/6c958bad/attachment-0001.html From matzew at apache.org Tue Dec 2 11:51:46 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 2 Dec 2014 16:51:46 +0000 Subject: [aerogear-dev] use oracle database In-Reply-To: References: <1417092766.2700.15.camel@kpiwko-x220> Message-ID: Ok, I filed this ticket: https://hibernate.atlassian.net/browse/HHH-9526 Ivan, can you review this ticket and update, if needed? Thanks! -Matthias On Tue, Dec 2, 2014 at 9:35 AM, Ivan G?rtler wrote: > We used VARCHAR2 ... but max value is lower than 4K ... > > yes ... the reason for LONG is large size ... and LONG in oracle have > much problems ... e.g. it is imposible use LONG in "where" -> exception > > *Mgr. Ivan G?rtler* > Mobile software developer > > AHEAD iTec, s.r.o., Botanick? 554/68a, > 602 00 Brno (Czech Republic) > > www.ahead-itec.com | twitter | mobile > security solutions > > 2014-12-01 20:49 GMT+01:00 Matthias Wessendorf : > >> >> >> On Monday, December 1, 2014, Ivan G?rtler >> wrote: >> >>> Problem is with Instalation Table ... object Instalation have "String >>> deviceToken..." and in database it is LONG ... >>> >> >> weird, because type is string. >> Is hibernate getting that mapping wrong? >> >> >> >>> when we try add Instalation to Aerogear ... it threw exception ... when >>> we hardly changed in database LONG to VARCHAR(255) it is ok ... >>> >> >> you want it a bit larger: >> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/resources/META-INF/orm.xml#L44 >> >> is that large size the reason for LONG being used? >> >> >> >>> but it is not a solution ... there in no problem with table >>> PushMessageInformation alhough it also contains LONG column >>> When we try in wildfly again it has same problem ... >>> And the worst is that LONG is deprecated in Oracle ... and CLOB should >>> be used >>> >>> *Mgr. Ivan G?rtler* >>> Mobile software developer >>> >>> AHEAD iTec, s.r.o., Botanick? 554/68a, >>> 602 00 Brno (Czech Republic) >>> >>> www.ahead-itec.com | twitter | >>> mobile security solutions >>> >>> 2014-11-27 13:52 GMT+01:00 Karel Piwko : >>> >>>> Hi Ivan, >>>> >>>> I'll have time to check your setup starting next week and I'll try >>>> reproduce the problem. I would appreciate if you can send me exact >>>> commit sha of UnifiedPush you are using as I've noticed that you are >>>> deploying -SNAPSHOT version. It would also help me to know whether you >>>> are able to reproduce the behavior with UPS 1.0.2 tag/release and >>>> detailed sql query log, that can be enabled in persistence.xml. >>>> >>>> Given the exception, I suspect that default Oracle dialect mapping has >>>> changed from Hibernate 4.1 (EAP 6.3.0) to Hibernate 4.3 (WF 9.0.0.A1). >>>> >>>> Thanks, >>>> >>>> Karel >>>> >>>> >>>> On Wed, 2014-11-26 at 17:21 +0100, Ivan G?rtler wrote: >>>> > Hi, >>>> > I tried to use aerogear with oracle database. When I used wildfly it >>>> was >>>> > good. >>>> > >>>> > I create module.xml for "ojdbc6-12.1.0.1.jar": >>>> > >>>> > ** >>>> > >>>> > ** >>>> > * * >>>> > * * >>>> > * * >>>> > * * >>>> > * * >>>> > * * >>>> > * * >>>> > * * >>>> > ** >>>> > >>>> > next I create oracle-database-config-wildfly.cli >>>> > >>>> > *# $WILDFLY_HOME/bin/jboss-cli.sh --file=/path/to/this/file.* >>>> > *connect* >>>> > *batch* >>>> > >>>> > *## Add Oracle driver* >>>> > >>>> */subsystem=datasources/jdbc-driver=oracleup:add(driver-name=oracleup,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)* >>>> > >>>> > *## Add UnifiedPush Datasource* >>>> > *data-source add --name=UnifiedPushDS --driver-name=oracleup >>>> > --jndi-name=java:jboss/datasources/UnifiedPushDS >>>> > --connection-url=jdbc:oracle:thin:@localhost:1521:XE >>>> > --user-name=unifiedpush --password=unifiedpush --use-ccm=false >>>> > --max-pool-size=25 --blocking-timeout-wait-millis=5000 --enabled=true* >>>> > >>>> > *run-batch* >>>> > *#:reload* >>>> > >>>> > next I configurate wildfly with this and deploy 2 war files. It was >>>> very >>>> > good :) >>>> > >>>> > But when I tried it with EAP 6.3.0 with same "ojdbc6-12.1.0.1.jar", >>>> > module.xml and >>>> > next oracle-database-config.cli >>>> > >>>> > *# $JBOSS_HOME/bin/jboss-cli.sh --file=/path/to/this/file.* >>>> > *connect* >>>> > *batch* >>>> > >>>> > *## Add Oracle driver* >>>> > >>>> */subsystem=datasources/jdbc-driver=oracleup:add(driver-name=oracleup,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)* >>>> > >>>> > *## Add UnifiedPush Datasource* >>>> > *data-source add --name=UnifiedPushDS --driver-name=oracleup >>>> > --jndi-name=java:jboss/datasources/UnifiedPushDS >>>> > --connection-url=jdbc:oracle:thin:@localhost:1521:XE >>>> > --user-name=unifiedpush --password=unifiedpush --use-ccm=false >>>> > --max-pool-size=25 --blocking-timeout-wait-millis=5000* >>>> > *data-source enable --name=UnifiedPushDS* >>>> > >>>> > *run-batch* >>>> > *#:reload* >>>> > >>>> > >>>> > after configurating database and deploying 2 war files (ag-push.war >>>> > specialy for AS7), it started Aerogear administration web UI and I can >>>> > login to web interface. After creating application and variant, I >>>> tried to >>>> > register mobile device in AG with successfull status in mobile >>>> device, but >>>> > without creating instalation in AG and server threw exception (log) >>>> > >>>> > *17:10:06,593 WARN [org.jboss.resteasy.core.ResourceLocator] >>>> > (http-/0.0.0.0:8080-2) Field uriInfo of subresource >>>> > org.keycloak.services.resources.PublicRealmResource will not be >>>> injected >>>> > according to spec* >>>> > *17:10:06,594 WARN [org.jboss.resteasy.core.ResourceLocator] >>>> > (http-/0.0.0.0:8080-2) Field request of subresource >>>> > org.keycloak.services.resources.PublicRealmResource will not be >>>> injected >>>> > according to spec* >>>> > *17:10:06,594 WARN [org.jboss.resteasy.core.ResourceLocator] >>>> > (http-/0.0.0.0:8080-2) Field response of subresource >>>> > org.keycloak.services.resources.PublicRealmResource will not be >>>> injected >>>> > according to spec* >>>> > *17:10:06,671 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] >>>> > (http-/0.0.0.0:8080-1) Found BeanManager at java:comp/BeanManager* >>>> > *17:10:06,698 INFO [org.jboss.resteasy.spi.ResteasyDeployment] >>>> > (http-/0.0.0.0:8080-1) Deploying javax.ws.rs.core.Application: class >>>> > >>>> org.jboss.aerogear.unifiedpush.rest.RestApplication$Proxy$_$$_WeldClientProxy* >>>> > *17:10:07,074 WARN >>>> [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (EJB >>>> > default - 1) SQL Error: 997, SQLState: 42000* >>>> > *17:10:07,074 ERROR >>>> [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (EJB >>>> > default - 1) ORA-00997: illegal use of LONG datatype* >>>> > >>>> > *17:10:07,094 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 1) >>>> > JBAS014134: EJB Invocation failed on component >>>> > ClientInstallationServiceImpl for method public abstract void >>>> > >>>> org.jboss.aerogear.unifiedpush.service.ClientInstallationService.addInstallation(org.jboss.aerogear.unifiedpush.api.Variant,org.jboss.aerogear.unifiedpush.api.Installation): >>>> > javax.ejb.EJBException: javax.persistence.PersistenceException: >>>> > org.hibernate.exception.SQLGrammarException: could not extract >>>> ResultSet* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:274) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:339) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) >>>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) >>>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) >>>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182) >>>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$1.runInvocation(AsyncFutureInterceptorFactory.java:89) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>> > [rt.jar:1.7.0_67]* >>>> > * at >>>> > >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>> > [rt.jar:1.7.0_67]* >>>> > * at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]* >>>> > * at org.jboss.threads.JBossThread.run(JBossThread.java:122)* >>>> > *Caused by: javax.persistence.PersistenceException: >>>> > org.hibernate.exception.SQLGrammarException: could not extract >>>> ResultSet* >>>> > * at >>>> > >>>> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387) >>>> > >>>> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> > >>>> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310) >>>> > >>>> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:277) >>>> > >>>> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPAInstallationDao.getSingleResultForQuery(JPAInstallationDao.java:199) >>>> > [unifiedpush-model-jpa-1.1.0-SNAPSHOT.jar:]* >>>> > * at >>>> > >>>> org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPAInstallationDao.findInstallationForVariantByDeviceToken(JPAInstallationDao.java:72) >>>> > [unifiedpush-model-jpa-1.1.0-SNAPSHOT.jar:]* >>>> > * at >>>> > >>>> org.jboss.aerogear.unifiedpush.service.impl.ClientInstallationServiceImpl.findInstallationForVariantByDeviceToken(ClientInstallationServiceImpl.java:177) >>>> > [unifiedpush-service-1.1.0-SNAPSHOT.jar:]* >>>> > * at >>>> > >>>> org.jboss.aerogear.unifiedpush.service.impl.ClientInstallationServiceImpl.addInstallation(ClientInstallationServiceImpl.java:51) >>>> > [unifiedpush-service-1.1.0-SNAPSHOT.jar:]* >>>> > * at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> > [rt.jar:1.7.0_67]* >>>> > * at >>>> > >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>> > [rt.jar:1.7.0_67]* >>>> > * at >>>> > >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> > [rt.jar:1.7.0_67]* >>>> > * at java.lang.reflect.Method.invoke(Method.java:606) >>>> [rt.jar:1.7.0_67]* >>>> > * at >>>> > >>>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) >>>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >>>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:86) >>>> > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:97) >>>> > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >>>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >>>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) >>>> > [jboss-as-jpa-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:93) >>>> > [jboss-as-weld-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) >>>> > [jboss-as-ee-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * at >>>> > >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) >>>> > [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]* >>>> > * at >>>> > >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:272) >>>> > [jboss-as-ejb3-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11]* >>>> > * ... 25 more* >>>> > *Caused by: org.hibernate.exception.SQLGrammarException: could not >>>> extract >>>> > ResultSet* >>>> > * at >>>> > >>>> org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:82) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> > >>>> org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> > >>>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:124) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> > >>>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> > >>>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:88) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.loader.Loader.getResultSet(Loader.java:2062) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1859) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1838) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.loader.Loader.doQuery(Loader.java:906) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> > >>>> org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:348) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.loader.Loader.doList(Loader.java:2550) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.loader.Loader.doList(Loader.java:2536) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2366) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.loader.Loader.list(Loader.java:2361) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:495) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> > >>>> org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:357) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at >>>> > >>>> org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:198) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1194) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:268) >>>> > >>>> [hibernate-entitymanager-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * ... 60 more* >>>> > *Caused by: java.sql.SQLSyntaxErrorException: ORA-00997: illegal use >>>> of >>>> > LONG datatype* >>>> > >>>> > * at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)* >>>> > * at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)* >>>> > * at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1017)* >>>> > * at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:655)* >>>> > * at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:249)* >>>> > * at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:566)* >>>> > * at >>>> > >>>> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:215)* >>>> > * at >>>> > >>>> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:58)* >>>> > * at >>>> > >>>> oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:776)* >>>> > * at >>>> > >>>> oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:897)* >>>> > * at >>>> > >>>> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1034)* >>>> > * at >>>> > >>>> oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3820)* >>>> > * at >>>> > >>>> oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3867)* >>>> > * at >>>> > >>>> oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1502)* >>>> > * at >>>> > >>>> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)* >>>> > * at >>>> > >>>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:79) >>>> > [hibernate-core-4.2.12.Final-redhat-1.jar:4.2.12.Final-redhat-1]* >>>> > * ... 75 more* >>>> > >>>> > I use same ojdbc6-12.1.0.1.jar and same database with wildfly and EAP >>>> ... I >>>> > tried to fix it for a 3 days, but I haven't found solution. >>>> > >>>> > Can you help me with this problem? Thanks. >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev at lists.jboss.org >>>> > https://lists.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 > -- 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/20141202/d82f8f5f/attachment-0001.html From scm.blanc at gmail.com Tue Dec 2 14:06:50 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Tue, 2 Dec 2014 20:06:50 +0100 Subject: [aerogear-dev] [Unified Push Server] Improving the message delivery to GCM In-Reply-To: References: Message-ID: <291A11E8-F3B9-421D-8258-03C215343157@gmail.com> Envoy? de mon iPhone > Le 2 d?c. 2014 ? 17:41, Matthias Wessendorf a ?crit : > > Hello! > > right now, we use HTTP (via Google's Sender), and they only allow 1000 tokens, per request to GCM, that means, we have a lot of (blocking) requests (see below trace). > We loop over the our 'processGCM', which internally invokes the HTTP sender from google: > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L118-L129 > (they use HttpUrlConnection inside of that 'sender') > > I see some improvements here: > * make the requests to google concurrent > * use persistent XMPP connection (https://issues.jboss.org/browse/AGPUSH-36) +1 that looks nice ! Do you see that for 1.1 ? > > Regarding AGPUSH-36 we could extract that into a tiny libray, to be used by UPS (like we did with others). Make sense ! > > > Greetings, > Matthias > > > {sending some requests to GCM, in a loop with blocking http request} > 21:13:00,059 INFO [GCMPushNotificationSender] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:01,568 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:02,646 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:03,495 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:04,291 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:05,171 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:06,054 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:06,982 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:07,846 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:08,748 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:09,662 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:10,527 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:11,384 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:12,253 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:13,349 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:14,283 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:15,164 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:16,004 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:16,796 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:17,620 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:18,407 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:19,158 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:19,942 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:20,696 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:21,587 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:22,388 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:23,055 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:23,763 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:24,490 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:25,351 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:26,125 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:26,857 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:27,545 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:28,208 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:28,865 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:29,523 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:30,299 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:30,973 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:31,588 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:32,196 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:32,796 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:33,404 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:34,174 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:34,799 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:35,354 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:35,893 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:36,449 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:36,991 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [1000] devices to GCM > 21:13:37,488 INFO [ClientInstallationServiceImpl] (EJB default - 2) Sending payload for [10] devices to GCM // yes, I had 48010 devices > 21:13:37,525 INFO [ClientInstallationServiceImpl] (EJB default - 2) Message to GCM has been submitted > > -- > 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/20141202/a537a651/attachment.html From matzew at apache.org Tue Dec 2 16:41:41 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 2 Dec 2014 21:41:41 +0000 Subject: [aerogear-dev] [Unified Push Server] Improving the message delivery to GCM In-Reply-To: <291A11E8-F3B9-421D-8258-03C215343157@gmail.com> References: <291A11E8-F3B9-421D-8258-03C215343157@gmail.com> Message-ID: On Tuesday, December 2, 2014, S?bastien Blanc wrote: > > > Envoy? de mon iPhone > > Le 2 d?c. 2014 ? 17:41, Matthias Wessendorf > a ?crit : > > Hello! > > right now, we use HTTP (via Google's Sender), and they only allow 1000 > tokens, per request to GCM, that means, we have a lot of (blocking) > requests (see below trace). > We loop over the our 'processGCM', which internally invokes the HTTP > sender from google: > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L118-L129 > (they use HttpUrlConnection inside of that 'sender') > > I see some improvements here: > * make the requests to google concurrent > * use persistent XMPP connection ( > https://issues.jboss.org/browse/AGPUSH-36) > > +1 that looks nice ! > Do you see that for 1.1 ? > yes; only > > > > Regarding AGPUSH-36 we could extract that into a tiny libray, to be used > by UPS (like we did with others). > > Make sense ! > > > > Greetings, > Matthias > > > {sending some requests to GCM, in a loop with blocking http request} > 21:13:00,059 INFO [GCMPushNotificationSender] (EJB default - 2) Sending > payload for [1000] devices to GCM > 21:13:01,568 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:02,646 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:03,495 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:04,291 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:05,171 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:06,054 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:06,982 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:07,846 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:08,748 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:09,662 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:10,527 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:11,384 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:12,253 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:13,349 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:14,283 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:15,164 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:16,004 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:16,796 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:17,620 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:18,407 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:19,158 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:19,942 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:20,696 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:21,587 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:22,388 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:23,055 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:23,763 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:24,490 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:25,351 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:26,125 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:26,857 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:27,545 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:28,208 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:28,865 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:29,523 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:30,299 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:30,973 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:31,588 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:32,196 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:32,796 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:33,404 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:34,174 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:34,799 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:35,354 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:35,893 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:36,449 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:36,991 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [1000] devices to GCM > 21:13:37,488 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Sending payload for [10] devices to GCM // yes, I had 48010 devices > 21:13:37,525 INFO [ClientInstallationServiceImpl] (EJB default - 2) > Message to GCM has been submitted > > -- > 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/20141202/30e3b49b/attachment-0001.html From edewit at redhat.com Tue Dec 2 16:45:09 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 2 Dec 2014 22:45:09 +0100 Subject: [aerogear-dev] [UPS] Geolocation Support In-Reply-To: <547DD3C4.6010301@redhat.com> References: <547C8D49.4050506@redhat.com> <547DD3C4.6010301@redhat.com> Message-ID: On 2 Dec,2014, at 15:59 , Summers Pittman wrote: > On 12/01/2014 10:57 AM, Sebastien Blanc wrote: >> >> >> On Mon, Dec 1, 2014 at 4:46 PM, Summers Pittman wrote: >> What other companies provide geofencing and what do their APIs look like? >> I know Google has some stuff for Android buried in Google Play Services. >> >> In general I think it might be less big brother if instead of the user reporting their location we add in metadata to filter incoming messages. This will have us sending more metadata but we don't have to worry about what if some bad guy compromises the server and start following his mother-in-law. >> Sorry, I'm not sure to understand the alternative you propose. > I don't like the push server knowing every user's location. Instead of the push server deciding to send to a user based on her location the push server should send a "filter" property with the message the client can use to determine if it should show the message. This is a cool option for android, but it can?t work on the other platforms as they have no way to filter the message before it shows up on the device. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141202/31552373/attachment.html From edewit at redhat.com Tue Dec 2 17:11:09 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 2 Dec 2014 23:11:09 +0100 Subject: [aerogear-dev] Aerogear Website Design In-Reply-To: <370366896.357610.1417534610821.JavaMail.zimbra@redhat.com> References: <380258845.154073.1417017253168.JavaMail.zimbra@redhat.com> <1253638600.156030.1417018406375.JavaMail.zimbra@redhat.com> <904046218.157588.1417020881718.JavaMail.zimbra@redhat.com> <547C64B5.40700@redhat.com> <48170895.317221.1417471841439.JavaMail.zimbra@redhat.com> <648973FA-8F69-4824-B180-E7733019F5C5@redhat.com> <370366896.357610.1417534610821.JavaMail.zimbra@redhat.com> Message-ID: On 2 Dec,2014, at 16:36 , Andres Galante wrote: > Thanks Erik, I've added Windows. > Nice, like it one more question can we use the robot as an icon for cordova? http://cordova.apache.org/images/logo_full.png > On our current website we have different structures for each platform documentation: > > Android looks like this: > http://aerogear.org/docs/specs/aerogear-android/ > > iOS like this: > http://aerogear.org/docs/specs/aerogear-ios-oauth2/ > These are generated API docs and people are used to the layout, we could make it the same maybe, would take some time I don?t know it?s pretty common for them to be crappy ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141202/43e80b78/attachment.html From agalante at redhat.com Tue Dec 2 17:35:01 2014 From: agalante at redhat.com (Andres Galante) Date: Tue, 2 Dec 2014 17:35:01 -0500 (EST) Subject: [aerogear-dev] Aerogear Website Design In-Reply-To: <370366896.357610.1417534610821.JavaMail.zimbra@redhat.com> References: <380258845.154073.1417017253168.JavaMail.zimbra@redhat.com> <904046218.157588.1417020881718.JavaMail.zimbra@redhat.com> <547C64B5.40700@redhat.com> <48170895.317221.1417471841439.JavaMail.zimbra@redhat.com> <648973FA-8F69-4824-B180-E7733019F5C5@redhat.com> <370366896.357610.1417534610821.JavaMail.zimbra@redhat.com> Message-ID: <1958651851.379482.1417559701377.JavaMail.zimbra@redhat.com> Hi! Updates on the website: I've finish structures for community and docs. And I am planning to use the same structure with the submenu to accommodate demos, roadmap and guides. To see the submenu with more options visit android docs. Please review the structure, tomorrow I'll add styles and make it look nice. Use Safari or Firefox: http://andresgalante.com/aerogearwebsite/ Thanks! ----- Original Message ----- From: "Andres Galante" To: "AeroGear Developer Mailing List" Sent: Tuesday, December 2, 2014 12:36:50 PM Subject: Re: [aerogear-dev] Aerogear Website Design Thanks Erik, I've added Windows. On our current website we have different structures for each platform documentation: Android looks like this: http://aerogear.org/docs/specs/aerogear-android/ iOS like this: http://aerogear.org/docs/specs/aerogear-ios-oauth2/ and others are on the structure of the website. The question is: Can we put everything under the same structure? Will it be too hard to move the docs? At the moment the structure of the docs I am doing looks like this: http://andresgalante.com/aerogearwebsite/docs_home.html What do you think? ----- Original Message ----- From: "Erik Jan de Wit" To: "AeroGear Developer Mailing List" Sent: Tuesday, December 2, 2014 4:21:39 AM Subject: Re: [aerogear-dev] Aerogear Website Design On 1 Dec,2014, at 23:10 , Andres Galante wrote: > Hi! > > Updates on the website: > > - I have change the structure a bit to accommodate the information we have on the website now. Added links to Roadmap, Guides and Demos under "Docs" tab. Contributors and Team will be under "community" > > - I have added a part on the homepage to show the platforms. > > - I will work on styles later this week. For now please review structure, help me see if this structure can support our content. > > - I've worked today on Home, Features and Get Started, will work tomorrow on docs and community. And later this week on styling, colors and make it look good. Love what you are doing with it, really nice. > > - I've started an illustration to use on the homepage main banner. This is a first idea (also not finished, sorry). > https://dl.dropboxusercontent.com/u/4371641/test_home.png > > - About the search, I left it there for now. We can remove it :) Our site is pretty static now, but I agree with you we can use google for it. > > Please view it on Safari or Firfox to understand my idea with the header: > > http://andresgalante.com/aerogearwebsite/index.html > Just wondering would this be a good time to add windows to the platform lists? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 agalante at redhat.com Tue Dec 2 17:41:18 2014 From: agalante at redhat.com (Andres Galante) Date: Tue, 2 Dec 2014 17:41:18 -0500 (EST) Subject: [aerogear-dev] Aerogear Website Design In-Reply-To: References: <380258845.154073.1417017253168.JavaMail.zimbra@redhat.com> <904046218.157588.1417020881718.JavaMail.zimbra@redhat.com> <547C64B5.40700@redhat.com> <48170895.317221.1417471841439.JavaMail.zimbra@redhat.com> <648973FA-8F69-4824-B180-E7733019F5C5@redhat.com> <370366896.357610.1417534610821.JavaMail.zimbra@redhat.com> Message-ID: <673130981.379682.1417560078457.JavaMail.zimbra@redhat.com> @erik yes I will use the cordova logo. That logo is not on the icon set I am using, so it was easier for me to put a square at this stage. I'll change it for the robot later. About docs, I've built the structure that can contain them and we can decide if we are migrating it or not later. ----- Original Message ----- From: "Erik Jan de Wit" To: "AeroGear Developer Mailing List" Sent: Tuesday, December 2, 2014 7:11:09 PM Subject: Re: [aerogear-dev] Aerogear Website Design On 2 Dec,2014, at 16:36 , Andres Galante wrote: > Thanks Erik, I've added Windows. > Nice, like it one more question can we use the robot as an icon for cordova? http://cordova.apache.org/images/logo_full.png > On our current website we have different structures for each platform documentation: > > Android looks like this: > http://aerogear.org/docs/specs/aerogear-android/ > > iOS like this: > http://aerogear.org/docs/specs/aerogear-ios-oauth2/ > These are generated API docs and people are used to the layout, we could make it the same maybe, would take some time I don?t know it?s pretty common for them to be crappy ;) _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Wed Dec 3 02:34:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 3 Dec 2014 07:34:53 +0000 Subject: [aerogear-dev] Small thought on repos naming In-Reply-To: <958675CD-7F50-486C-B41C-C200FCDD0B2E@gmail.com> References: <958675CD-7F50-486C-B41C-C200FCDD0B2E@gmail.com> Message-ID: On Tuesday, December 2, 2014, Corinne Krych wrote: > Hello > > Last June we talked about aligning your repo naming convention, as a > result ios repos were renamed: > aerogear-ios-LIB_NAME > > like we have: > aerogear-android-LIB_NAME > aerogear-js-LIB_NAME > > Would it make sense to have: > aerogear-cordova-LIB_NAME instead of aerogear-LIB_NAME-cordova > > @edewit wdyt? yes, that would be nice -Matthias > > ++ > Corinne > > PS: we still have some exception (which will need renaming) like > aerogear-otp-js but OTP libes are conssitant across platforms though... > _______________________________________________ > 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/20141203/06afbaed/attachment.html From edewit at redhat.com Wed Dec 3 02:37:00 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 3 Dec 2014 08:37:00 +0100 Subject: [aerogear-dev] Small thought on repos naming In-Reply-To: References: <958675CD-7F50-486C-B41C-C200FCDD0B2E@gmail.com> Message-ID: > @edewit wdyt? > > yes, that would be nice > Yeah, would be nice, as all will be ordered on platform -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141203/21440274/attachment.html From daniel.bevenius at gmail.com Wed Dec 3 02:50:33 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 3 Dec 2014 08:50:33 +0100 Subject: [aerogear-dev] Small thought on repos naming In-Reply-To: References: <958675CD-7F50-486C-B41C-C200FCDD0B2E@gmail.com> Message-ID: +1 On 3 December 2014 at 08:37, Erik Jan de Wit wrote: > @edewit wdyt? > > > yes, that would be nice > > Yeah, would be nice, as all will be ordered on platform > > > _______________________________________________ > 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/20141203/91f82c22/attachment-0001.html From ivan.gurtler at ahead-itec.com Wed Dec 3 03:18:33 2014 From: ivan.gurtler at ahead-itec.com (=?UTF-8?Q?Ivan_G=C3=BCrtler?=) Date: Wed, 3 Dec 2014 09:18:33 +0100 Subject: [aerogear-dev] use oracle database In-Reply-To: References: <1417092766.2700.15.camel@kpiwko-x220> Message-ID: We find that problem is with hibernate + oracle (not with EAP... becasue we found same problem in wildfly) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141203/c9743abe/attachment.html From scm.blanc at gmail.com Wed Dec 3 04:36:41 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 3 Dec 2014 10:36:41 +0100 Subject: [aerogear-dev] UnifiedPush-java-client 1.1.0-alpha.1 release Message-ID: Hi folk, Following the UPS alpha.1 release, we have also staged a Java Sender 1.1.0-alpha.1. Along some bug fixes, we have : - Support for the new Sender Message format. - Builder API has been polished. - Push Configuration can be externalized in a json file. the staging repo is : https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4405 Please test and vote ! Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141203/3e4fd65e/attachment.html From matzew at apache.org Wed Dec 3 05:43:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 3 Dec 2014 10:43:28 +0000 Subject: [aerogear-dev] use oracle database In-Reply-To: References: <1417092766.2700.15.camel@kpiwko-x220> Message-ID: Thanks for the feedback, I updated the ticket On Wed, Dec 3, 2014 at 8:18 AM, Ivan G?rtler wrote: > We find that problem is with hibernate + oracle (not with EAP... becasue > we found same problem in wildfly) > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141203/2a7f4575/attachment.html From daniel.bevenius at gmail.com Wed Dec 3 05:46:45 2014 From: daniel.bevenius at gmail.com (danielbevenius) Date: Wed, 3 Dec 2014 03:46:45 -0700 (MST) Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: References: <53FB369B.9020205@redhat.com> Message-ID: <1417603605031-10240.post@n5.nabble.com> I'd like to delete the restsync module from the differential-synchronization branch. As mentioned previously in this thread, I thought it might be nice to have it around but it is causing more confusion and not really being used. Let me know anyone objects. If not I'd like to delete it tomorrow. Thanks, /Dan -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-aerogear-sync-server-repository-tp9016p10240.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Wed Dec 3 05:57:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 3 Dec 2014 10:57:02 +0000 Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: <1417603605031-10240.post@n5.nabble.com> References: <53FB369B.9020205@redhat.com> <1417603605031-10240.post@n5.nabble.com> Message-ID: On Wed, Dec 3, 2014 at 10:46 AM, danielbevenius wrote: > I'd like to delete the restsync > < > https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization/restsync > > > module from the differential-synchronization branch. > As mentioned previously in this thread, I thought it might be nice to have > it around but it is causing more confusion and not really being used. > +1 > > Let me know anyone objects. If not I'd like to delete it tomorrow. > would it make sense to extract it, as a demo/example? But well, not sure that makes sense since it may not be maintained, right ? > > Thanks, > > /Dan > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-aerogear-sync-server-repository-tp9016p10240.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/20141203/f0d978be/attachment.html From daniel.bevenius at gmail.com Wed Dec 3 05:59:10 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 3 Dec 2014 11:59:10 +0100 Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: References: <53FB369B.9020205@redhat.com> <1417603605031-10240.post@n5.nabble.com> Message-ID: >would it make sense to extract it, as a demo/example? We could do that if we find a need for it later. But at the moment I think we have enough to maintain as it is. On 3 December 2014 at 11:57, Matthias Wessendorf wrote: > > > On Wed, Dec 3, 2014 at 10:46 AM, danielbevenius > wrote: > >> I'd like to delete the restsync >> < >> https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization/restsync >> > >> module from the differential-synchronization branch. >> As mentioned previously in this thread, I thought it might be nice to have >> it around but it is causing more confusion and not really being used. >> > > +1 > > >> >> Let me know anyone objects. If not I'd like to delete it tomorrow. >> > > would it make sense to extract it, as a demo/example? > But well, not sure that makes sense since it may not be maintained, right ? > > > > >> >> Thanks, >> >> /Dan >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-aerogear-sync-server-repository-tp9016p10240.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/20141203/d2c17d62/attachment.html From supittma at redhat.com Wed Dec 3 09:45:07 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 03 Dec 2014 09:45:07 -0500 Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: <1417603605031-10240.post@n5.nabble.com> References: <53FB369B.9020205@redhat.com> <1417603605031-10240.post@n5.nabble.com> Message-ID: <547F21F3.6030009@redhat.com> On 12/03/2014 05:46 AM, danielbevenius wrote: > I'd like to delete the restsync > > module from the differential-synchronization branch. > As mentioned previously in this thread, I thought it might be nice to have > it around but it is causing more confusion and not really being used. > > Let me know anyone objects. If not I'd like to delete it tomorrow. killitwithfire.gif > > Thanks, > > /Dan > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-aerogear-sync-server-repository-tp9016p10240.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 -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From lukas.fryc at gmail.com Wed Dec 3 10:44:36 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 3 Dec 2014 16:44:36 +0100 Subject: [aerogear-dev] AGPUSH-1047 - Heads up In-Reply-To: References: <20141127175205.GB67384@abstractj.org> <20141127175606.GA67510@abstractj.org> <20141128165810.GA81269@abstractj.org> Message-ID: Hey man, I gave it one more chance and this time I was able to make it work without (almost) any hassle. I just had to change app.js to redirect to correct keycloak instance: https://github.com/lfryc/aerogear-unifiedpush-server/commit/3824e373b1164a2654c759b5f761095a559669d0 abstractj++ On Fri, Nov 28, 2014 at 6:33 PM, Luk?? Fry? wrote: > Yep, that make sense, I was accessing it through the port-forward bound to > localhost. > > On Fri, Nov 28, 2014 at 5:58 PM, Bruno Oliveira > wrote: > >> Ahoy my friend, the keycloak instance is running here with docker at >> 10.0.1.7 and the other wildfly instance with UPS on localhost. >> >> Does it make sense to you? >> >> On 2014-11-28, Luk?? Fry? wrote: >> > Hey Bruno, thanks for detailed instriuctions, the last comment saved me >> > some time. :-) >> > >> > I have followed your instructions, except binding Keycloak to >> > localhost:10080 and deploying WildFly to localhost:8080. >> > I have configured keycloak.url appropriately, but then I get >> > http://localhost:8080/ag-push/: >> > >> > Unable to resolve realm public key remotely, status = 404 >> > >> > I wonder, how you configured two wildfly instances, Keycloak's and >> UPS's to >> > avoid conflict? >> > As I said, I used Keycloak on another port, but that didn't seem to >> work. >> > >> > ~ Lukas >> > >> > >> > On Thu, Nov 27, 2014 at 6:56 PM, Bruno Oliveira >> wrote: >> > >> > > /system-property=keycloak.url:add(value=" >> http://authserverip:8080/auth") >> > > >> >> > _______________________________________________ >> > 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/20141203/31f7de4b/attachment.html From kpiwko at redhat.com Wed Dec 3 11:51:10 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 03 Dec 2014 17:51:10 +0100 Subject: [aerogear-dev] Call for arms - deprecating some projects In-Reply-To: <20141202141508.GA75820@abstractj.org> References: <20141202141508.GA75820@abstractj.org> Message-ID: <1417625470.2623.2.camel@kpiwko-x220> I not sure what is the plan but renaming repositories to zzz_deprecated-{{repo-name}} or something similar would help here as well. Currently there are too many repositories and navigate via right repositories is quite a lot of effort. Karel On Tue, 2014-12-02 at 12:15 -0200, Bruno Oliveira wrote: > Good morning, while I was doing some security stuff. I found > projects no longer maintained at our organization. I think we should add > a deprecation to inform our community that these projects are no longer > maintained[1]. > > I would like your help reviewing which projects are no longer supported > on AeroGear[2], otherwise I do it until the end of this week. > > Thanks in advance. > > > [1] - > https://github.com/aerogear/aerogear-security/blob/master/README.md > [2] - https://github.com/aerogear > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Wed Dec 3 12:37:01 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 3 Dec 2014 15:37:01 -0200 Subject: [aerogear-dev] Call for arms - deprecating some projects In-Reply-To: <1417625470.2623.2.camel@kpiwko-x220> References: <20141202141508.GA75820@abstractj.org> <1417625470.2623.2.camel@kpiwko-x220> Message-ID: The plan is to add a deprecate notice at the repository and include it at description, pretty much like https://github.com/aerogear/aerogear-security-hawk On Wed, Dec 3, 2014 at 2:51 PM, Karel Piwko wrote: > I not sure what is the plan but renaming repositories to > zzz_deprecated-{{repo-name}} or something similar would help here as > well. > > Currently there are too many repositories and navigate via right > repositories is quite a lot of effort. > > Karel > > > On Tue, 2014-12-02 at 12:15 -0200, Bruno Oliveira wrote: > > Good morning, while I was doing some security stuff. I found > > projects no longer maintained at our organization. I think we should add > > a deprecation to inform our community that these projects are no longer > > maintained[1]. > > > > I would like your help reviewing which projects are no longer supported > > on AeroGear[2], otherwise I do it until the end of this week. > > > > Thanks in advance. > > > > > > [1] - > > https://github.com/aerogear/aerogear-security/blob/master/README.md > > [2] - https://github.com/aerogear > > > > -- > > > > 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141203/c5359902/attachment.html From bruno at abstractj.org Wed Dec 3 13:08:38 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 3 Dec 2014 16:08:38 -0200 Subject: [aerogear-dev] AGPUSH-1047 - Heads up In-Reply-To: References: <20141127175205.GB67384@abstractj.org> <20141127175606.GA67510@abstractj.org> <20141128165810.GA81269@abstractj.org> Message-ID: <20141203180838.GB13050@abstractj.org> Lovely! I need more arms and brains to figure out how to dinamically inform the remote URL for app.js. Any idea is welcome. On 2014-12-03, Luk?? Fry? wrote: > Hey man, > > I gave it one more chance and this time I was able to make it work without > (almost) any hassle. > > I just had to change app.js to redirect to correct keycloak instance: > https://github.com/lfryc/aerogear-unifiedpush-server/commit/3824e373b1164a2654c759b5f761095a559669d0 > > abstractj++ > > On Fri, Nov 28, 2014 at 6:33 PM, Luk?? Fry? wrote: > > > Yep, that make sense, I was accessing it through the port-forward bound to > > localhost. > > > > On Fri, Nov 28, 2014 at 5:58 PM, Bruno Oliveira > > wrote: > > > >> Ahoy my friend, the keycloak instance is running here with docker at > >> 10.0.1.7 and the other wildfly instance with UPS on localhost. > >> > >> Does it make sense to you? > >> > >> On 2014-11-28, Luk?? Fry? wrote: > >> > Hey Bruno, thanks for detailed instriuctions, the last comment saved me > >> > some time. :-) > >> > > >> > I have followed your instructions, except binding Keycloak to > >> > localhost:10080 and deploying WildFly to localhost:8080. > >> > I have configured keycloak.url appropriately, but then I get > >> > http://localhost:8080/ag-push/: > >> > > >> > Unable to resolve realm public key remotely, status = 404 > >> > > >> > I wonder, how you configured two wildfly instances, Keycloak's and > >> UPS's to > >> > avoid conflict? > >> > As I said, I used Keycloak on another port, but that didn't seem to > >> work. > >> > > >> > ~ Lukas > >> > > >> > > >> > On Thu, Nov 27, 2014 at 6:56 PM, Bruno Oliveira > >> wrote: > >> > > >> > > /system-property=keycloak.url:add(value=" > >> http://authserverip:8080/auth") > >> > > > >> > >> > _______________________________________________ > >> > 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 scm.blanc at gmail.com Thu Dec 4 05:16:14 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 4 Dec 2014 11:16:14 +0100 Subject: [aerogear-dev] UnifiedPush Server 1.1.0-alpha.1 with Windows Push is out ! Message-ID: Hi, We are happy to announce that the Unified Push Server 1.1.0-alpha.1 has been released ! What is new ? The big new feature is the support of Windows Push ! Take a look at our Windows Push HelloWorld quickstart and the Windows Tutorial to help you to get started. Another cool feature that has been added is the Import/Export of installations. From the admin console, you can now easily extract in JSON format all the installations from a variant. The same way, you can import a set of installations for a particular variant. Besides that, a bunch of bugs have been fixed, you can check the full list here . Stay tuned ! http://aerogear.org/news/2014/12/03/aerogear-unified-push-alpha1-is-out/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141204/c2ecb4f1/attachment-0001.html From bruno at abstractj.org Thu Dec 4 05:45:47 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 4 Dec 2014 08:45:47 -0200 Subject: [aerogear-dev] Keycloak and passport.js Message-ID: <20141204104547.GB30278@abstractj.org> Good morning my friends, with the support of JS and KC team. The passport.js module is working with KC[1]. Instructions about how to run are available here[2]. I'm planning to release 0.1.0.Alpha today or maybe tomorrow. It depends pretty much of the feedback. You're welcome for testing. [1] - https://github.com/abstractj/passport-keycloak/tree/goose [2] - https://github.com/abstractj/passport-keycloak/blob/goose/README.md -- abstractj PGP: 0x84DC9914 From andreas.rosdal at gmail.com Thu Dec 4 06:43:56 2014 From: andreas.rosdal at gmail.com (=?UTF-8?Q?Andreas_R=C3=B8sdal?=) Date: Thu, 4 Dec 2014 12:43:56 +0100 Subject: [aerogear-dev] Registration error with iOS on AeroGear UnifiedPush Server Message-ID: Hello! I would appreciate some help in resolving a problem I have with registering a new iOS device token to the AeroGear UnifiedPush Server. We are using aerogear-ios-push on iOS 8.1.1, and AeroGear UnifiedPush Server version 1.0.2 running on Wildfly. Registering a new device token works correctly with a test certificate, and we were able to send push messages correctly. However, when time came to register a new device using the production certificates in the iOS variant in the UnifiedPush Server, we got an error message in the iPhone app. This is the error message we got: http://imgur.com/w7t9zLd This error was generated by showing an alert with the response from the server. Note the AGPushErrorDomain AGNetworkingOperationFailingURLRequestErrorKey in the screenshot above. Thanks for the positive response from this mailing list so far! Regards, Andreas R. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141204/a389527c/attachment.html From matzew at apache.org Thu Dec 4 07:11:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 4 Dec 2014 12:11:45 +0000 Subject: [aerogear-dev] Keycloak and passport.js In-Reply-To: <20141204104547.GB30278@abstractj.org> References: <20141204104547.GB30278@abstractj.org> Message-ID: Bruno, that is really awesome! On Thu, Dec 4, 2014 at 10:45 AM, Bruno Oliveira wrote: > Good morning my friends, with the support of JS and KC team. The > passport.js module is working with KC[1]. Instructions about how to run > are available here[2]. > > I'm planning to release 0.1.0.Alpha today or maybe tomorrow. It depends > pretty much of the feedback. > > You're welcome for testing. > > [1] - https://github.com/abstractj/passport-keycloak/tree/goose > [2] - > https://github.com/abstractj/passport-keycloak/blob/goose/README.md > > -- > > 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/20141204/7e64d5b9/attachment.html From matzew at apache.org Thu Dec 4 07:16:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 4 Dec 2014 12:16:37 +0000 Subject: [aerogear-dev] Registration error with iOS on AeroGear UnifiedPush Server In-Reply-To: References: Message-ID: Looks similar to this issue: https://issues.jboss.org/browse/AGCORDOVA-38 Erik, perhaps it is part of iOS native, on 8.x ? Instead of 'just' Cordova ? On Thu, Dec 4, 2014 at 11:43 AM, Andreas R?sdal wrote: > Hello! > > I would appreciate some help in resolving a problem I have with > registering a new iOS device token to the AeroGear UnifiedPush Server. > > We are using aerogear-ios-push on iOS 8.1.1, and AeroGear UnifiedPush > Server version 1.0.2 running on Wildfly. > > Registering a new device token works correctly with a test certificate, > and we were able to send push messages correctly. However, when time came > to register a new device using the production certificates in the iOS > variant in the UnifiedPush Server, we got an error message in the iPhone > app. > > This is the error message we got: > http://imgur.com/w7t9zLd > > This error was generated by showing an alert with the response from the > server. Note the AGPushErrorDomain > AGNetworkingOperationFailingURLRequestErrorKey in the screenshot above. > > Thanks for the positive response from this mailing list so far! > > Regards, > Andreas R. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141204/9855bee3/attachment.html From agalante at redhat.com Thu Dec 4 07:30:16 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 4 Dec 2014 07:30:16 -0500 (EST) Subject: [aerogear-dev] Aerogear Website Design In-Reply-To: <673130981.379682.1417560078457.JavaMail.zimbra@redhat.com> References: <380258845.154073.1417017253168.JavaMail.zimbra@redhat.com> <547C64B5.40700@redhat.com> <48170895.317221.1417471841439.JavaMail.zimbra@redhat.com> <648973FA-8F69-4824-B180-E7733019F5C5@redhat.com> <370366896.357610.1417534610821.JavaMail.zimbra@redhat.com> <673130981.379682.1417560078457.JavaMail.zimbra@redhat.com> Message-ID: <1720559918.482069.1417696216108.JavaMail.zimbra@redhat.com> Hi! After a talking with Erik and Lukas yesterday I've made some changes to the website structure. Homepage: - There is a news section - highlights will be logos of docker, open shift, feed henry and any other place where aerogear is available. Features: - Push went up - Get started btn got larger and the others smaller Get started: - The idea is to add code snippets before every download btn making it a getting started page rather than a download page. Guides: - Added coockbooks to the menu - Move Contribute guides to Community Roadmap: - Added jira and github updates Community: - Added contributor News: - This will be an aggregator of all blog posts, tweets, videos and events. Please preview it on safari or Firefox (i will install the polyfill today): http://andresgalante.com/aerogearwebsite/ I'll work on styles, colors and making it look good today and tomorrow. Any reference, change, critic or feedback if very welcome. Thanks! ----- Original Message ----- From: "Andres Galante" To: "AeroGear Developer Mailing List" Sent: Tuesday, December 2, 2014 7:41:18 PM Subject: Re: [aerogear-dev] Aerogear Website Design @erik yes I will use the cordova logo. That logo is not on the icon set I am using, so it was easier for me to put a square at this stage. I'll change it for the robot later. About docs, I've built the structure that can contain them and we can decide if we are migrating it or not later. ----- Original Message ----- From: "Erik Jan de Wit" To: "AeroGear Developer Mailing List" Sent: Tuesday, December 2, 2014 7:11:09 PM Subject: Re: [aerogear-dev] Aerogear Website Design On 2 Dec,2014, at 16:36 , Andres Galante wrote: > Thanks Erik, I've added Windows. > Nice, like it one more question can we use the robot as an icon for cordova? http://cordova.apache.org/images/logo_full.png > On our current website we have different structures for each platform documentation: > > Android looks like this: > http://aerogear.org/docs/specs/aerogear-android/ > > iOS like this: > http://aerogear.org/docs/specs/aerogear-ios-oauth2/ > These are generated API docs and people are used to the layout, we could make it the same maybe, would take some time I don?t know it?s pretty common for them to be crappy ;) _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 andreas.rosdal at gmail.com Thu Dec 4 08:08:55 2014 From: andreas.rosdal at gmail.com (=?UTF-8?Q?Andreas_R=C3=B8sdal?=) Date: Thu, 4 Dec 2014 14:08:55 +0100 Subject: [aerogear-dev] Registration error with iOS on AeroGear UnifiedPush Server In-Reply-To: References: Message-ID: Good to know there is a similar issue! This is iOS 8 native. The error is in application:didRegisterForRemoteNotificationsWithDeviceToken The token is verified to be valid and can be used to send push messages. Is there anything I can do to debug this problem further? Regards, Andreas R. 2014-12-04 13:16 GMT+01:00 Matthias Wessendorf : > Looks similar to this issue: > > https://issues.jboss.org/browse/AGCORDOVA-38 > > Erik, perhaps it is part of iOS native, on 8.x ? Instead of 'just' Cordova > ? > > On Thu, Dec 4, 2014 at 11:43 AM, Andreas R?sdal > wrote: > >> Hello! >> >> I would appreciate some help in resolving a problem I have with >> registering a new iOS device token to the AeroGear UnifiedPush Server. >> >> We are using aerogear-ios-push on iOS 8.1.1, and AeroGear UnifiedPush >> Server version 1.0.2 running on Wildfly. >> >> Registering a new device token works correctly with a test certificate, >> and we were able to send push messages correctly. However, when time came >> to register a new device using the production certificates in the iOS >> variant in the UnifiedPush Server, we got an error message in the iPhone >> app. >> >> This is the error message we got: >> http://imgur.com/w7t9zLd >> >> This error was generated by showing an alert with the response from the >> server. Note the AGPushErrorDomain >> AGNetworkingOperationFailingURLRequestErrorKey in the screenshot above. >> >> Thanks for the positive response from this mailing list so far! >> >> Regards, >> Andreas R. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141204/5db72eac/attachment-0001.html From edewit at redhat.com Thu Dec 4 08:14:00 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 04 Dec 2014 14:14:00 +0100 Subject: [aerogear-dev] Registration error with iOS on AeroGear UnifiedPush Server In-Reply-To: References: Message-ID: <54805E18.4080003@redhat.com> Hi, > Registering a new device token works correctly with a test > certificate, and we were able to send push messages correctly. > However, when time came to register a new device using the production > certificates in the iOS variant in the UnifiedPush Server, we got an > error message in the iPhone app. > > This is the error message we got: > http://imgur.com/w7t9zLd > I don't know what steps you took to switch to a production certificate, but it looks that you might have recreated the variant? This error is shown when you try to register with invalid credentials (e.g. wrong variantId and secret). Could you check and make sure these are still valid? Cheers, Erik Jan From edewit at redhat.com Thu Dec 4 08:22:11 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 04 Dec 2014 14:22:11 +0100 Subject: [aerogear-dev] Registration error with iOS on AeroGear UnifiedPush Server In-Reply-To: References: Message-ID: <54806003.4090803@redhat.com> On 04/12/2014 13:16, Matthias Wessendorf wrote: > Looks similar to this issue: > > https://issues.jboss.org/browse/AGCORDOVA-38 > > Erik, perhaps it is part of iOS native, on 8.x ? Instead of 'just' > Cordova ? > Nope this issue _is_ the error that Andreas reported, but here it's about how this error is passed to the javascript api. The cause of this error is the same as Andreas namely incorrect variantId and secret resulting in a 401 http response code. From andreas.rosdal at gmail.com Thu Dec 4 09:01:30 2014 From: andreas.rosdal at gmail.com (=?UTF-8?Q?Andreas_R=C3=B8sdal?=) Date: Thu, 4 Dec 2014 15:01:30 +0100 Subject: [aerogear-dev] Registration error with iOS on AeroGear UnifiedPush Server In-Reply-To: <54806003.4090803@redhat.com> References: <54806003.4090803@redhat.com> Message-ID: The problem was indeed incorrect variantId and secret in the app. Thanks for the help again! Regards, Andreas R. 2014-12-04 14:22 GMT+01:00 Erik Jan de Wit : > > On 04/12/2014 13:16, Matthias Wessendorf wrote: > > Looks similar to this issue: > > > > https://issues.jboss.org/browse/AGCORDOVA-38 > > > > Erik, perhaps it is part of iOS native, on 8.x ? Instead of 'just' > > Cordova ? > > > Nope this issue _is_ the error that Andreas reported, but here it's > about how this error is passed to the javascript api. The cause of this > error is the same as Andreas namely incorrect variantId and secret > resulting in a 401 http response code. > _______________________________________________ > 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/20141204/c77a26b4/attachment.html From matzew at apache.org Thu Dec 4 09:07:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 4 Dec 2014 14:07:39 +0000 Subject: [aerogear-dev] Registration error with iOS on AeroGear UnifiedPush Server In-Reply-To: <54806003.4090803@redhat.com> References: <54806003.4090803@redhat.com> Message-ID: On Thu, Dec 4, 2014 at 1:22 PM, Erik Jan de Wit wrote: > > On 04/12/2014 13:16, Matthias Wessendorf wrote: > > Looks similar to this issue: > > > > https://issues.jboss.org/browse/AGCORDOVA-38 > > > > Erik, perhaps it is part of iOS native, on 8.x ? Instead of 'just' > > Cordova ? > > > Nope this issue _is_ the error that Andreas reported, but here it's > about how this error is passed to the javascript api. The cause of this > error is the same as Andreas namely incorrect variantId and secret > resulting in a 401 http response code. > I wonder if the 'failure' block could respond a bit nicer, in that case :-) -M > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141204/c37d99f2/attachment.html From scm.blanc at gmail.com Thu Dec 4 09:23:24 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 4 Dec 2014 15:23:24 +0100 Subject: [aerogear-dev] UnifiedPush Java Sender Forge Addon Message-ID: Hi ! I'm happy to announce the first release of the UPS Java Sender Forge Addon, This addon will help the developer to integrate the Java Sender into their existing applications. Basically it provides 2 commands : - unifiedpush-setup : will pull in the dependency and create a pushConfiguration.json file that contains the needed information (UPS url, PushAppID and master secret) -unifiedpush-generate-service : will generate a small service that wraps the Java Sender, you can then easily inject it into your business logic. The nice thing about Forge 2 Addons, is that you get JBDS Integration for "free" , so these 2 commands are available in JBDS as UI Wizards. I created a blog entry for that which also contains a screencast : http://blog-sblanc.rhcloud.com/?p=66 The code is hosted here for now : https://github.com/sebastienblanc/unifiedpush-addon but will soon be migrated under the AeroGear org. Regards, Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141204/762a9a79/attachment.html From lholmqui at redhat.com Thu Dec 4 10:15:23 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 4 Dec 2014 10:15:23 -0500 Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: <547F21F3.6030009@redhat.com> References: <53FB369B.9020205@redhat.com> <1417603605031-10240.post@n5.nabble.com> <547F21F3.6030009@redhat.com> Message-ID: <1822F6B8-63DD-4BE3-9825-946CF50603CD@redhat.com> lets delete it. we still have the ?spec? on aerogear.org that says what to do on the 409? > On Dec 3, 2014, at 9:45 AM, Summers Pittman wrote: > > On 12/03/2014 05:46 AM, danielbevenius wrote: >> I'd like to delete the restsync >> >> module from the differential-synchronization branch. >> As mentioned previously in this thread, I thought it might be nice to have >> it around but it is causing more confusion and not really being used. >> >> Let me know anyone objects. If not I'd like to delete it tomorrow. > killitwithfire.gif >> >> Thanks, >> >> /Dan >> >> >> >> -- >> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-aerogear-sync-server-repository-tp9016p10240.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 > > > -- > 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 daniel.bevenius at gmail.com Thu Dec 4 10:19:46 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 4 Dec 2014 16:19:46 +0100 Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: <1822F6B8-63DD-4BE3-9825-946CF50603CD@redhat.com> References: <53FB369B.9020205@redhat.com> <1417603605031-10240.post@n5.nabble.com> <547F21F3.6030009@redhat.com> <1822F6B8-63DD-4BE3-9825-946CF50603CD@redhat.com> Message-ID: >we still have the ?spec? on aerogear.org that says what to do on the 409? Good point, the spec pages need updating. At the moment they are is still valid, that for conflict resolution our client libraries require that the server be able to return a 409 and the latest version of the stored document. This is more about removing this particular server. It was just an example for testing. On 4 December 2014 at 16:15, Lucas Holmquist wrote: > lets delete it. > > we still have the ?spec? on aerogear.org that says what to do on the 409? > > On Dec 3, 2014, at 9:45 AM, Summers Pittman wrote: > > > > On 12/03/2014 05:46 AM, danielbevenius wrote: > >> I'd like to delete the restsync > >> < > https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization/restsync > > > >> module from the differential-synchronization branch. > >> As mentioned previously in this thread, I thought it might be nice to > have > >> it around but it is causing more confusion and not really being used. > >> > >> Let me know anyone objects. If not I'd like to delete it tomorrow. > > killitwithfire.gif > >> > >> Thanks, > >> > >> /Dan > >> > >> > >> > >> -- > >> View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-aerogear-sync-server-repository-tp9016p10240.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 > > > > > > -- > > 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/20141204/ea7934c2/attachment-0001.html From lholmqui at redhat.com Thu Dec 4 10:21:46 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 4 Dec 2014 10:21:46 -0500 Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: References: <53FB369B.9020205@redhat.com> <1417603605031-10240.post@n5.nabble.com> <547F21F3.6030009@redhat.com> <1822F6B8-63DD-4BE3-9825-946CF50603CD@redhat.com> Message-ID: <692123B0-70FA-4B97-9D98-97C68612EBB5@redhat.com> > On Dec 4, 2014, at 10:19 AM, Daniel Bevenius wrote: > > >we still have the ?spec? on aerogear.org that says what to do on the 409? > Good point, the spec pages need updating. At the moment they are is still valid, that for conflict resolution our client libraries require that the server be able to return a 409 and the latest version of the stored document. This is more about removing this particular server. It was just an example for testing yup. FINISH HIM!!! > > On 4 December 2014 at 16:15, Lucas Holmquist > wrote: > lets delete it. > > we still have the ?spec? on aerogear.org that says what to do on the 409? > > On Dec 3, 2014, at 9:45 AM, Summers Pittman > wrote: > > > > On 12/03/2014 05:46 AM, danielbevenius wrote: > >> I'd like to delete the restsync > >> > > >> module from the differential-synchronization branch. > >> As mentioned previously in this thread, I thought it might be nice to have > >> it around but it is causing more confusion and not really being used. > >> > >> Let me know anyone objects. If not I'd like to delete it tomorrow. > > killitwithfire.gif > >> > >> Thanks, > >> > >> /Dan > >> > >> > >> > >> -- > >> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-aerogear-sync-server-repository-tp9016p10240.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 > > > > > > -- > > 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 > _______________________________________________ > 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/20141204/5f140da4/attachment.html From scm.blanc at gmail.com Thu Dec 4 10:59:43 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 4 Dec 2014 16:59:43 +0100 Subject: [aerogear-dev] UnifiedPush Java Sender Forge Addon In-Reply-To: References: Message-ID: FYI, The repo has been migrated (Thanks Matthias) : https://github.com/aerogear/unifiedpush-forge-addon And the addon is visible on the Forge Website (Thanks George) : http://forge.jboss.org/addon/org.jboss.aerogear:unifiedpush On Thu, Dec 4, 2014 at 3:23 PM, Sebastien Blanc wrote: > Hi ! > > I'm happy to announce the first release of the UPS Java Sender Forge > Addon, This addon will help the developer to integrate the Java Sender into > their existing applications. > > Basically it provides 2 commands : > - unifiedpush-setup : will pull in the dependency and create a > pushConfiguration.json file that contains the needed information (UPS url, > PushAppID and master secret) > -unifiedpush-generate-service : will generate a small service that wraps > the Java Sender, you can then easily inject it into your business logic. > > The nice thing about Forge 2 Addons, is that you get JBDS Integration for > "free" , so these 2 commands are available in JBDS as UI Wizards. > > I created a blog entry for that which also contains a screencast : > http://blog-sblanc.rhcloud.com/?p=66 > > The code is hosted here for now : > https://github.com/sebastienblanc/unifiedpush-addon but will soon be > migrated under the AeroGear org. > > Regards, > Sebi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141204/9be17f64/attachment.html From klinux at gmail.com Thu Dec 4 14:40:23 2014 From: klinux at gmail.com (Kleber Rocha) Date: Thu, 4 Dec 2014 17:40:23 -0200 Subject: [aerogear-dev] Update from 1.0.2 to 1.1.0alpha Message-ID: Hi there, I trying to update my aerogear-unifiedpush-server from 1.0.2 to 1.1.0alpha, but I'm having this error: Caused by: org.postgresql.util.PSQLException: Large Objects may not be used in auto-commit mode. at org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:260) at org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:189) at org.postgresql.jdbc2.AbstractJdbc2BlobClob.(AbstractJdbc2BlobClob.java:45) at org.postgresql.jdbc2.AbstractJdbc2Blob.(AbstractJdbc2Blob.java:19) at org.postgresql.jdbc3.AbstractJdbc3Blob.(AbstractJdbc3Blob.java:17) at org.postgresql.jdbc4.AbstractJdbc4Blob.(AbstractJdbc4Blob.java:18) at org.postgresql.jdbc4.Jdbc4Blob.(Jdbc4Blob.java:18) at org.postgresql.jdbc4.Jdbc4ResultSet.makeBlob(Jdbc4ResultSet.java:41) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBlob(AbstractJdbc2ResultSet.java:379) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBlob(AbstractJdbc2ResultSet.java:367) at org.jboss.jca.adapters.jdbc.WrappedResultSet.getBlob(WrappedResultSet.java:573) at org.hibernate.type.descriptor.sql.BlobTypeDescriptor$1.doExtract(BlobTypeDescriptor.java:65) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:267) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:263) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:338) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2969) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.loadFromResultSet(EntityReferenceInitializerImpl.java:324) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] ... 85 more Did you saw something about this? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141204/17fdcb5b/attachment.html From agalante at redhat.com Thu Dec 4 15:51:05 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 4 Dec 2014 15:51:05 -0500 (EST) Subject: [aerogear-dev] Website color options In-Reply-To: <1396751483.513030.1417726074418.JavaMail.zimbra@redhat.com> Message-ID: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> Hi! I've done some color testing: http://andresgalante.com/aerogearwebsite/colortest.html I have my favorite but it doesn't matter what I think, this website should appeal to developers. What do you think? From qmx at qmx.me Thu Dec 4 16:00:05 2014 From: qmx at qmx.me (Douglas Campos) Date: Thu, 04 Dec 2014 19:00:05 -0200 Subject: [aerogear-dev] Website color options In-Reply-To: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> Message-ID: <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> Is there any "method or reasoning" behind choosing colors? I like green blue and orange, but it's just personal taste :) On December 4, 2014 6:51:05 PM GMT-02:00, Andres Galante wrote: >Hi! > >I've done some color testing: > >http://andresgalante.com/aerogearwebsite/colortest.html > >I have my favorite but it doesn't matter what I think, this website >should appeal to developers. > >What do you think? > >_______________________________________________ >aerogear-dev mailing list >aerogear-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/aerogear-dev -- qmx From agalante at redhat.com Thu Dec 4 17:04:01 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 4 Dec 2014 17:04:01 -0500 (EST) Subject: [aerogear-dev] Website color options In-Reply-To: <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> Message-ID: <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> Blue and orange are the colors of the logo, gray is neutral, red is the hat. ----- Original Message ----- From: "Douglas Campos" To: "AeroGear Developer Mailing List" Sent: Thursday, December 4, 2014 6:00:05 PM Subject: Re: [aerogear-dev] Website color options Is there any "method or reasoning" behind choosing colors? I like green blue and orange, but it's just personal taste :) On December 4, 2014 6:51:05 PM GMT-02:00, Andres Galante wrote: >Hi! > >I've done some color testing: > >http://andresgalante.com/aerogearwebsite/colortest.html > >I have my favorite but it doesn't matter what I think, this website >should appeal to developers. > >What do you think? > >_______________________________________________ >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 From daniel.bevenius at gmail.com Fri Dec 5 03:24:18 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 5 Dec 2014 09:24:18 +0100 Subject: [aerogear-dev] Website color options In-Reply-To: <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> Message-ID: I like the orange. On 4 December 2014 at 23:04, Andres Galante wrote: > Blue and orange are the colors of the logo, gray is neutral, red is the > hat. > > > > > ----- Original Message ----- > From: "Douglas Campos" > To: "AeroGear Developer Mailing List" > Sent: Thursday, December 4, 2014 6:00:05 PM > Subject: Re: [aerogear-dev] Website color options > > Is there any "method or reasoning" behind choosing colors? I like green > blue and orange, but it's just personal taste :) > > On December 4, 2014 6:51:05 PM GMT-02:00, Andres Galante < > agalante at redhat.com> wrote: > >Hi! > > > >I've done some color testing: > > > >http://andresgalante.com/aerogearwebsite/colortest.html > > > >I have my favorite but it doesn't matter what I think, this website > >should appeal to developers. > > > >What do you think? > > > >_______________________________________________ > >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 > _______________________________________________ > 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/20141205/9ac47206/attachment.html From matzew at apache.org Fri Dec 5 04:46:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 5 Dec 2014 09:46:37 +0000 Subject: [aerogear-dev] Update from 1.0.2 to 1.1.0alpha In-Reply-To: References: Message-ID: actually, I have not seen this so far :-( Thanks for sharing the info, I have filed a ticket for us to look into it: https://issues.jboss.org/browse/AGPUSH-1128 On Thu, Dec 4, 2014 at 7:40 PM, Kleber Rocha wrote: > Hi there, > > I trying to update my aerogear-unifiedpush-server from 1.0.2 to > 1.1.0alpha, but I'm having this error: > > Caused by: org.postgresql.util.PSQLException: Large Objects may not be > used in auto-commit mode. > at > org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:260) > at > org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:189) > at > org.postgresql.jdbc2.AbstractJdbc2BlobClob.(AbstractJdbc2BlobClob.java:45) > at > org.postgresql.jdbc2.AbstractJdbc2Blob.(AbstractJdbc2Blob.java:19) > at > org.postgresql.jdbc3.AbstractJdbc3Blob.(AbstractJdbc3Blob.java:17) > at > org.postgresql.jdbc4.AbstractJdbc4Blob.(AbstractJdbc4Blob.java:18) > at org.postgresql.jdbc4.Jdbc4Blob.(Jdbc4Blob.java:18) > at org.postgresql.jdbc4.Jdbc4ResultSet.makeBlob(Jdbc4ResultSet.java:41) > at > org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBlob(AbstractJdbc2ResultSet.java:379) > at > org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBlob(AbstractJdbc2ResultSet.java:367) > at > org.jboss.jca.adapters.jdbc.WrappedResultSet.getBlob(WrappedResultSet.java:573) > at > org.hibernate.type.descriptor.sql.BlobTypeDescriptor$1.doExtract(BlobTypeDescriptor.java:65) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:267) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:263) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:338) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2969) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.loadFromResultSet(EntityReferenceInitializerImpl.java:324) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > ... 85 more > > Did you saw something about this? > > Thanks > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141205/0e8c6d09/attachment.html From daniel at passos.me Fri Dec 5 05:25:13 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 5 Dec 2014 08:25:13 -0200 Subject: [aerogear-dev] Website color options In-Reply-To: References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> Message-ID: Green On Fri, Dec 5, 2014 at 6:24 AM, Daniel Bevenius wrote: > I like the orange. > > On 4 December 2014 at 23:04, Andres Galante wrote: > >> Blue and orange are the colors of the logo, gray is neutral, red is the >> hat. >> >> >> >> >> ----- Original Message ----- >> From: "Douglas Campos" >> To: "AeroGear Developer Mailing List" >> Sent: Thursday, December 4, 2014 6:00:05 PM >> Subject: Re: [aerogear-dev] Website color options >> >> Is there any "method or reasoning" behind choosing colors? I like green >> blue and orange, but it's just personal taste :) >> >> On December 4, 2014 6:51:05 PM GMT-02:00, Andres Galante < >> agalante at redhat.com> wrote: >> >Hi! >> > >> >I've done some color testing: >> > >> >http://andresgalante.com/aerogearwebsite/colortest.html >> > >> >I have my favorite but it doesn't matter what I think, this website >> >should appeal to developers. >> > >> >What do you think? >> > >> >_______________________________________________ >> >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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141205/a8349bba/attachment.html From agalante at redhat.com Fri Dec 5 07:38:22 2014 From: agalante at redhat.com (Andres Galante) Date: Fri, 5 Dec 2014 07:38:22 -0500 (EST) Subject: [aerogear-dev] Website color options In-Reply-To: References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> Message-ID: <712293148.543852.1417783102526.JavaMail.zimbra@redhat.com> I added 2 more options. They are the same pastel Blue and orange of the logo. http://andresgalante.com/aerogearwebsite/colortest.html ----- Original Message ----- From: "Daniel Passos" To: "AeroGear Developer Mailing List" Sent: Friday, December 5, 2014 7:25:13 AM Subject: Re: [aerogear-dev] Website color options Green On Fri, Dec 5, 2014 at 6:24 AM, Daniel Bevenius < daniel.bevenius at gmail.com > wrote: I like the orange. On 4 December 2014 at 23:04, Andres Galante < agalante at redhat.com > wrote: Blue and orange are the colors of the logo, gray is neutral, red is the hat. ----- Original Message ----- From: "Douglas Campos" < qmx at qmx.me > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Thursday, December 4, 2014 6:00:05 PM Subject: Re: [aerogear-dev] Website color options Is there any "method or reasoning" behind choosing colors? I like green blue and orange, but it's just personal taste :) On December 4, 2014 6:51:05 PM GMT-02:00, Andres Galante < agalante at redhat.com > wrote: >Hi! > >I've done some color testing: > > http://andresgalante.com/aerogearwebsite/colortest.html > >I have my favorite but it doesn't matter what I think, this website >should appeal to developers. > >What do you think? > >_______________________________________________ >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 _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 edewit at redhat.com Fri Dec 5 09:05:20 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 05 Dec 2014 15:05:20 +0100 Subject: [aerogear-dev] Website color options In-Reply-To: <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> Message-ID: <5481BBA0.5050406@redhat.com> I like the green and the orange ( I have to like orange ;) ), but I was wondering are we going to change the colours of the logo as well? Cause the colors of the site are not the same they are harder. When we use the logo with the colours we have now will it not look dated? There also seems that there are some missing images so maybe I'm missing something On 04/12/2014 23:04, Andres Galante wrote: > Blue and orange are the colors of the logo, gray is neutral, red is the hat. From supittma at redhat.com Fri Dec 5 09:38:33 2014 From: supittma at redhat.com (Summers Pittman) Date: Fri, 05 Dec 2014 09:38:33 -0500 Subject: [aerogear-dev] Website color options In-Reply-To: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> Message-ID: <5481C369.2090908@redhat.com> On 12/04/2014 03:51 PM, Andres Galante wrote: > Hi! > > I've done some color testing: > > http://andresgalante.com/aerogearwebsite/colortest.html > > I have my favorite but it doesn't matter what I think, this website should appeal to developers. > > What do you think? Red and Grey > > _______________________________________________ > 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 agalante at redhat.com Fri Dec 5 09:40:41 2014 From: agalante at redhat.com (Andres Galante) Date: Fri, 5 Dec 2014 09:40:41 -0500 (EST) Subject: [aerogear-dev] Website color options In-Reply-To: <5481BBA0.5050406@redhat.com> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> <5481BBA0.5050406@redhat.com> Message-ID: <1064347226.551934.1417790441529.JavaMail.zimbra@redhat.com> @erik I've reupload the images, should work now. Thera are 2 versions of the website following the colors of the logo. I like the blue one: http://andresgalante.com/aerogearwebsite/colortest.html The other options are test I did going bold on colors. Maybe we should narrow the choices on those first 2 (orange logo and blue logo) I must admit I am not a fan the logo, font choice is bad, type treatment is wrong, icon is completely wrong, "G" is deformed, gears centers are not centered, the braking on the height is absolutely wrong. The colors of the logo have too little contrast to work either on dark or light backgrounds. But I guess this is a matter for another day. ----- Original Message ----- From: "Erik Jan de Wit" To: "AeroGear Developer Mailing List" Sent: Friday, December 5, 2014 11:05:20 AM Subject: Re: [aerogear-dev] Website color options I like the green and the orange ( I have to like orange ;) ), but I was wondering are we going to change the colours of the logo as well? Cause the colors of the site are not the same they are harder. When we use the logo with the colours we have now will it not look dated? There also seems that there are some missing images so maybe I'm missing something On 04/12/2014 23:04, Andres Galante wrote: > Blue and orange are the colors of the logo, gray is neutral, red is the hat. _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From edewit at redhat.com Fri Dec 5 09:46:46 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 05 Dec 2014 15:46:46 +0100 Subject: [aerogear-dev] Website color options In-Reply-To: <1064347226.551934.1417790441529.JavaMail.zimbra@redhat.com> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> <5481BBA0.5050406@redhat.com> <1064347226.551934.1417790441529.JavaMail.zimbra@redhat.com> Message-ID: <5481C556.4040804@redhat.com> On 05/12/2014 15:40, Andres Galante wrote: > @erik I've reupload the images, should work now. Thanks > Thera are 2 versions of the website following the colors of the logo. I like the blue one: > > http://andresgalante.com/aerogearwebsite/colortest.html > > The other options are test I did going bold on colors. Maybe we should narrow the choices on those first 2 (orange logo and blue logo) Right I like the blue of the logo as well > I must admit I am not a fan the logo, font choice is bad, type treatment is wrong, icon is completely wrong, "G" is deformed, gears centers are not centered, the braking on the height is absolutely wrong. The colors of the logo have too little contrast to work either on dark or light backgrounds. But I guess this is a matter for another day. Hmm, right why not do that better as well, I see little sense in picking a colour to match the logo now when we are going to change the logo later. > > > > > ----- Original Message ----- > From: "Erik Jan de Wit" > To: "AeroGear Developer Mailing List" > Sent: Friday, December 5, 2014 11:05:20 AM > Subject: Re: [aerogear-dev] Website color options > > I like the green and the orange ( I have to like orange ;) ), but I was > wondering are we going to change the colours of the logo as well? Cause > the colors of the site are not the same they are harder. When we use the > logo with the colours we have now will it not look dated? There also > seems that there are some missing images so maybe I'm missing something > > On 04/12/2014 23:04, Andres Galante wrote: >> Blue and orange are the colors of the logo, gray is neutral, red is the hat. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 agalante at redhat.com Fri Dec 5 10:04:04 2014 From: agalante at redhat.com (Andres Galante) Date: Fri, 5 Dec 2014 10:04:04 -0500 (EST) Subject: [aerogear-dev] Website color options In-Reply-To: <5481C556.4040804@redhat.com> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> <5481BBA0.5050406@redhat.com> <1064347226.551934.1417790441529.JavaMail.zimbra@redhat.com> <5481C556.4040804@redhat.com> Message-ID: <1334793888.555017.1417791844810.JavaMail.zimbra@redhat.com> To be honest I don't think I am allow to change the logo :) Lets continue with it as it is. ----- Original Message ----- From: "Erik Jan de Wit" To: "AeroGear Developer Mailing List" Sent: Friday, December 5, 2014 11:46:46 AM Subject: Re: [aerogear-dev] Website color options On 05/12/2014 15:40, Andres Galante wrote: > @erik I've reupload the images, should work now. Thanks > Thera are 2 versions of the website following the colors of the logo. I like the blue one: > > http://andresgalante.com/aerogearwebsite/colortest.html > > The other options are test I did going bold on colors. Maybe we should narrow the choices on those first 2 (orange logo and blue logo) Right I like the blue of the logo as well > I must admit I am not a fan the logo, font choice is bad, type treatment is wrong, icon is completely wrong, "G" is deformed, gears centers are not centered, the braking on the height is absolutely wrong. The colors of the logo have too little contrast to work either on dark or light backgrounds. But I guess this is a matter for another day. Hmm, right why not do that better as well, I see little sense in picking a colour to match the logo now when we are going to change the logo later. > > > > > ----- Original Message ----- > From: "Erik Jan de Wit" > To: "AeroGear Developer Mailing List" > Sent: Friday, December 5, 2014 11:05:20 AM > Subject: Re: [aerogear-dev] Website color options > > I like the green and the orange ( I have to like orange ;) ), but I was > wondering are we going to change the colours of the logo as well? Cause > the colors of the site are not the same they are harder. When we use the > logo with the colours we have now will it not look dated? There also > seems that there are some missing images so maybe I'm missing something > > On 04/12/2014 23:04, Andres Galante wrote: >> Blue and orange are the colors of the logo, gray is neutral, red is the hat. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 lukas.fryc at gmail.com Fri Dec 5 10:05:19 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 5 Dec 2014 16:05:19 +0100 Subject: [aerogear-dev] [Poll] New Visual Style for UnifiedPush Server - Colours In-Reply-To: References: Message-ID: Ok, let's conclude this poll: 3x A: light 1x B: dark 1x C: darker 1x The current UPS style is better than proposed ones 1x BLACK AND YELLOW We hadn't have overwhelming number of responses, but I'd say that's fine, let's go with the original Gabriel's proposal, light - with buttons in same colors as the header. @Andres: In this case I can just reopen the PR [1] and I will try to change the button colours myself, I will ping you /wrt the result. :-) [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/384 https://issues.jboss.org/browse/AGPUSH-934 On Thu, Nov 27, 2014 at 2:41 PM, Luk?? Fry? wrote: > Hey guys, > > some time ago Gabriel prepared us a new scheme that we had two issues with > (that I won't mention so I won't influence your opinion). ;-) > > Andres now took this proposal one step further and prepared several > options. > > > You can vote for your favorite here, and leave any additional comments if > required: > > > https://docs.google.com/forms/d/1s8vs9lXlD8sE4rOWje0qGBzrzeZofSLhtWxGvf-TWdw/viewform?usp=send_form > > > > Thanks! > > ~ Lukas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141205/acc531b3/attachment.html From scm.blanc at gmail.com Fri Dec 5 10:50:55 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 5 Dec 2014 16:50:55 +0100 Subject: [aerogear-dev] Update from 1.0.2 to 1.1.0alpha In-Reply-To: References: Message-ID: Hi, I started to look at this. Could you give me more details : - Do you have this exception when starting the server ? Or when creating an app/variant - What for variants types do you have ? (iOS, Android ...) If possible please comment on the jira that Matthias open ( https://issues.jboss.org/browse/AGPUSH-1128 ) On Fri, Dec 5, 2014 at 10:46 AM, Matthias Wessendorf wrote: > actually, I have not seen this so far :-( > > Thanks for sharing the info, I have filed a ticket for us to look into it: > https://issues.jboss.org/browse/AGPUSH-1128 > > On Thu, Dec 4, 2014 at 7:40 PM, Kleber Rocha wrote: > >> Hi there, >> >> I trying to update my aerogear-unifiedpush-server from 1.0.2 to >> 1.1.0alpha, but I'm having this error: >> >> Caused by: org.postgresql.util.PSQLException: Large Objects may not be >> used in auto-commit mode. >> at >> org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:260) >> at >> org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:189) >> at >> org.postgresql.jdbc2.AbstractJdbc2BlobClob.(AbstractJdbc2BlobClob.java:45) >> at >> org.postgresql.jdbc2.AbstractJdbc2Blob.(AbstractJdbc2Blob.java:19) >> at >> org.postgresql.jdbc3.AbstractJdbc3Blob.(AbstractJdbc3Blob.java:17) >> at >> org.postgresql.jdbc4.AbstractJdbc4Blob.(AbstractJdbc4Blob.java:18) >> at org.postgresql.jdbc4.Jdbc4Blob.(Jdbc4Blob.java:18) >> at >> org.postgresql.jdbc4.Jdbc4ResultSet.makeBlob(Jdbc4ResultSet.java:41) >> at >> org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBlob(AbstractJdbc2ResultSet.java:379) >> at >> org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBlob(AbstractJdbc2ResultSet.java:367) >> at >> org.jboss.jca.adapters.jdbc.WrappedResultSet.getBlob(WrappedResultSet.java:573) >> at >> org.hibernate.type.descriptor.sql.BlobTypeDescriptor$1.doExtract(BlobTypeDescriptor.java:65) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:267) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:263) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:338) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2969) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.loadFromResultSet(EntityReferenceInitializerImpl.java:324) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> ... 85 more >> >> Did you saw something about this? >> >> Thanks >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141205/58871315/attachment-0001.html From corinnekrych at gmail.com Fri Dec 5 15:20:45 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 5 Dec 2014 21:20:45 +0100 Subject: [aerogear-dev] Website color options In-Reply-To: <1334793888.555017.1417791844810.JavaMail.zimbra@redhat.com> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> <5481BBA0.5050406@redhat.com> <1064347226.551934.1417790441529.JavaMail.zimbra@redhat.com> <5481C556.4040804@redhat.com> <1334793888.555017.1417791844810.JavaMail.zimbra@redhat.com> Message-ID: +1 with the blue from the logo ++ Corinne > On 05 Dec 2014, at 16:04, Andres Galante wrote: > > To be honest I don't think I am allow to change the logo :) Lets continue with it as it is. > > > > ----- Original Message ----- > From: "Erik Jan de Wit" > To: "AeroGear Developer Mailing List" > Sent: Friday, December 5, 2014 11:46:46 AM > Subject: Re: [aerogear-dev] Website color options > > > On 05/12/2014 15:40, Andres Galante wrote: >> @erik I've reupload the images, should work now. > Thanks >> Thera are 2 versions of the website following the colors of the logo. I like the blue one: >> >> http://andresgalante.com/aerogearwebsite/colortest.html >> >> The other options are test I did going bold on colors. Maybe we should narrow the choices on those first 2 (orange logo and blue logo) > Right I like the blue of the logo as well >> I must admit I am not a fan the logo, font choice is bad, type treatment is wrong, icon is completely wrong, "G" is deformed, gears centers are not centered, the braking on the height is absolutely wrong. The colors of the logo have too little contrast to work either on dark or light backgrounds. But I guess this is a matter for another day. > Hmm, right why not do that better as well, I see little sense in picking > a colour to match the logo now when we are going to change the logo later. >> >> >> >> >> ----- Original Message ----- >> From: "Erik Jan de Wit" >> To: "AeroGear Developer Mailing List" >> Sent: Friday, December 5, 2014 11:05:20 AM >> Subject: Re: [aerogear-dev] Website color options >> >> I like the green and the orange ( I have to like orange ;) ), but I was >> wondering are we going to change the colours of the logo as well? Cause >> the colors of the site are not the same they are harder. When we use the >> logo with the colours we have now will it not look dated? There also >> seems that there are some missing images so maybe I'm missing something >> >> On 04/12/2014 23:04, Andres Galante wrote: >>> Blue and orange are the colors of the logo, gray is neutral, red is the hat. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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 bruno at abstractj.org Fri Dec 5 15:48:49 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 5 Dec 2014 18:48:49 -0200 Subject: [aerogear-dev] Website color options In-Reply-To: References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> <5481BBA0.5050406@redhat.com> <1064347226.551934.1417790441529.JavaMail.zimbra@redhat.com> <5481C556.4040804@redhat.com> <1334793888.555017.1417791844810.JavaMail.zimbra@redhat.com> Message-ID: Red + Gray from my super personal taste. On Fri, Dec 5, 2014 at 6:20 PM, Corinne Krych wrote: > +1 with the blue from the logo > > ++ > Corinne > > On 05 Dec 2014, at 16:04, Andres Galante wrote: > > > > To be honest I don't think I am allow to change the logo :) Lets > continue with it as it is. > > > > > > > > ----- Original Message ----- > > From: "Erik Jan de Wit" > > To: "AeroGear Developer Mailing List" > > Sent: Friday, December 5, 2014 11:46:46 AM > > Subject: Re: [aerogear-dev] Website color options > > > > > > On 05/12/2014 15:40, Andres Galante wrote: > >> @erik I've reupload the images, should work now. > > Thanks > >> Thera are 2 versions of the website following the colors of the logo. I > like the blue one: > >> > >> http://andresgalante.com/aerogearwebsite/colortest.html > >> > >> The other options are test I did going bold on colors. Maybe we should > narrow the choices on those first 2 (orange logo and blue logo) > > Right I like the blue of the logo as well > >> I must admit I am not a fan the logo, font choice is bad, type > treatment is wrong, icon is completely wrong, "G" is deformed, gears > centers are not centered, the braking on the height is absolutely wrong. > The colors of the logo have too little contrast to work either on dark or > light backgrounds. But I guess this is a matter for another day. > > Hmm, right why not do that better as well, I see little sense in picking > > a colour to match the logo now when we are going to change the logo > later. > >> > >> > >> > >> > >> ----- Original Message ----- > >> From: "Erik Jan de Wit" > >> To: "AeroGear Developer Mailing List" > >> Sent: Friday, December 5, 2014 11:05:20 AM > >> Subject: Re: [aerogear-dev] Website color options > >> > >> I like the green and the orange ( I have to like orange ;) ), but I was > >> wondering are we going to change the colours of the logo as well? Cause > >> the colors of the site are not the same they are harder. When we use the > >> logo with the colours we have now will it not look dated? There also > >> seems that there are some missing images so maybe I'm missing something > >> > >> On 04/12/2014 23:04, Andres Galante wrote: > >>> Blue and orange are the colors of the logo, gray is neutral, red is > the hat. > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141205/7b7f495a/attachment.html From bruno at abstractj.org Fri Dec 5 15:51:20 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 5 Dec 2014 18:51:20 -0200 Subject: [aerogear-dev] Website color options In-Reply-To: References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <6E7EB789-C71E-4EE3-B381-69ED65B8C3FC@qmx.me> <1694793952.516959.1417730641585.JavaMail.zimbra@redhat.com> <5481BBA0.5050406@redhat.com> <1064347226.551934.1417790441529.JavaMail.zimbra@redhat.com> <5481C556.4040804@redhat.com> <1334793888.555017.1417791844810.JavaMail.zimbra@redhat.com> Message-ID: Also I would vote for creating a poll like Lukas did and tweet from aerogears account. We did that for people vote for the name WildFly, why not choose the colours of the website? On Fri, Dec 5, 2014 at 6:48 PM, Bruno Oliveira wrote: > Red + Gray from my super personal taste. > > > On Fri, Dec 5, 2014 at 6:20 PM, Corinne Krych > wrote: > >> +1 with the blue from the logo >> >> ++ >> Corinne >> > On 05 Dec 2014, at 16:04, Andres Galante wrote: >> > >> > To be honest I don't think I am allow to change the logo :) Lets >> continue with it as it is. >> > >> > >> > >> > ----- Original Message ----- >> > From: "Erik Jan de Wit" >> > To: "AeroGear Developer Mailing List" >> > Sent: Friday, December 5, 2014 11:46:46 AM >> > Subject: Re: [aerogear-dev] Website color options >> > >> > >> > On 05/12/2014 15:40, Andres Galante wrote: >> >> @erik I've reupload the images, should work now. >> > Thanks >> >> Thera are 2 versions of the website following the colors of the logo. >> I like the blue one: >> >> >> >> http://andresgalante.com/aerogearwebsite/colortest.html >> >> >> >> The other options are test I did going bold on colors. Maybe we should >> narrow the choices on those first 2 (orange logo and blue logo) >> > Right I like the blue of the logo as well >> >> I must admit I am not a fan the logo, font choice is bad, type >> treatment is wrong, icon is completely wrong, "G" is deformed, gears >> centers are not centered, the braking on the height is absolutely wrong. >> The colors of the logo have too little contrast to work either on dark or >> light backgrounds. But I guess this is a matter for another day. >> > Hmm, right why not do that better as well, I see little sense in picking >> > a colour to match the logo now when we are going to change the logo >> later. >> >> >> >> >> >> >> >> >> >> ----- Original Message ----- >> >> From: "Erik Jan de Wit" >> >> To: "AeroGear Developer Mailing List" >> >> Sent: Friday, December 5, 2014 11:05:20 AM >> >> Subject: Re: [aerogear-dev] Website color options >> >> >> >> I like the green and the orange ( I have to like orange ;) ), but I was >> >> wondering are we going to change the colours of the logo as well? Cause >> >> the colors of the site are not the same they are harder. When we use >> the >> >> logo with the colours we have now will it not look dated? There also >> >> seems that there are some missing images so maybe I'm missing something >> >> >> >> On 04/12/2014 23:04, Andres Galante wrote: >> >>> Blue and orange are the colors of the logo, gray is neutral, red is >> the hat. >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.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 >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141205/d3014003/attachment-0001.html From agalante at redhat.com Fri Dec 5 16:50:10 2014 From: agalante at redhat.com (Andres Galante) Date: Fri, 5 Dec 2014 16:50:10 -0500 (EST) Subject: [aerogear-dev] Website color options In-Reply-To: References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <5481BBA0.5050406@redhat.com> <1064347226.551934.1417790441529.JavaMail.zimbra@redhat.com> <5481C556.4040804@redhat.com> <1334793888.555017.1417791844810.JavaMail.zimbra@redhat.com> Message-ID: <703691432.583995.1417816210853.JavaMail.zimbra@redhat.com> Good idea, I would reduce the options to grey, logo blue or logo orange. Lukas how did you sent up the poll? ----- Original Message ----- From: "Bruno Oliveira" To: "AeroGear Developer Mailing List" Sent: Friday, December 5, 2014 5:51:20 PM Subject: Re: [aerogear-dev] Website color options Also I would vote for creating a poll like Lukas did and tweet from aerogears account. We did that for people vote for the name WildFly, why not choose the colours of the website? On Fri, Dec 5, 2014 at 6:48 PM, Bruno Oliveira wrote: > Red + Gray from my super personal taste. > > > On Fri, Dec 5, 2014 at 6:20 PM, Corinne Krych > wrote: > >> +1 with the blue from the logo >> >> ++ >> Corinne >> > On 05 Dec 2014, at 16:04, Andres Galante wrote: >> > >> > To be honest I don't think I am allow to change the logo :) Lets >> continue with it as it is. >> > >> > >> > >> > ----- Original Message ----- >> > From: "Erik Jan de Wit" >> > To: "AeroGear Developer Mailing List" >> > Sent: Friday, December 5, 2014 11:46:46 AM >> > Subject: Re: [aerogear-dev] Website color options >> > >> > >> > On 05/12/2014 15:40, Andres Galante wrote: >> >> @erik I've reupload the images, should work now. >> > Thanks >> >> Thera are 2 versions of the website following the colors of the logo. >> I like the blue one: >> >> >> >> http://andresgalante.com/aerogearwebsite/colortest.html >> >> >> >> The other options are test I did going bold on colors. Maybe we should >> narrow the choices on those first 2 (orange logo and blue logo) >> > Right I like the blue of the logo as well >> >> I must admit I am not a fan the logo, font choice is bad, type >> treatment is wrong, icon is completely wrong, "G" is deformed, gears >> centers are not centered, the braking on the height is absolutely wrong. >> The colors of the logo have too little contrast to work either on dark or >> light backgrounds. But I guess this is a matter for another day. >> > Hmm, right why not do that better as well, I see little sense in picking >> > a colour to match the logo now when we are going to change the logo >> later. >> >> >> >> >> >> >> >> >> >> ----- Original Message ----- >> >> From: "Erik Jan de Wit" >> >> To: "AeroGear Developer Mailing List" >> >> Sent: Friday, December 5, 2014 11:05:20 AM >> >> Subject: Re: [aerogear-dev] Website color options >> >> >> >> I like the green and the orange ( I have to like orange ;) ), but I was >> >> wondering are we going to change the colours of the logo as well? Cause >> >> the colors of the site are not the same they are harder. When we use >> the >> >> logo with the colours we have now will it not look dated? There also >> >> seems that there are some missing images so maybe I'm missing something >> >> >> >> On 04/12/2014 23:04, Andres Galante wrote: >> >>> Blue and orange are the colors of the logo, gray is neutral, red is >> the hat. >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.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 >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Sat Dec 6 06:09:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 6 Dec 2014 11:09:09 +0000 Subject: [aerogear-dev] [UPS] Geolocation Support In-Reply-To: <547DD3C4.6010301@redhat.com> References: <547C8D49.4050506@redhat.com> <547DD3C4.6010301@redhat.com> Message-ID: On Tue, Dec 2, 2014 at 2:59 PM, Summers Pittman wrote: > On 12/01/2014 10:57 AM, Sebastien Blanc wrote: > > > > On Mon, Dec 1, 2014 at 4:46 PM, Summers Pittman > wrote: > >> What other companies provide geofencing and what do their APIs look >> like? >> I know Google has some stuff for Android buried in Google Play Services. >> >> In general I think it might be less big brother if instead of the user >> reporting their location we add in metadata to filter incoming messages. >> This will have us sending more metadata but we don't have to worry about >> what if some bad guy compromises the server and start following his >> mother-in-law. >> > Sorry, I'm not sure to understand the alternative you propose. > > I don't like the push server knowing every user's location. > it should know nothing. Instead, the geo data should be stored on a 'geo server' component. -M > Instead of the push server deciding to send to a user based on her > location the push server should send a "filter" property with the message > the client can use to determine if it should show the message. > > > >> >> >> >> On 11/27/2014 11:52 AM, Sebastien Blanc wrote: >> >> Hi Folks ! >> >> During our last f2f we agreed on adding some geolocation support for the >> next UnifiedPush Release (1.1). I would like to start here a thread to >> discuss this topic. >> >> Let's keep in mind : *Crawl, Walk, Run* >> >> I would like to start with a concrete proposition and initiate the >> discussions from there : >> >> >> Installations >> Model >> Change >> >> The idea is to add 2 new fields to the Installation Object : >> >> double longitude; >> double latitude; >> >> >> These field *should* be optional ! >> >> >> Registration >> >> When the device registers, along with alias, categories etc ... it will >> also be possible to pass a latitude and longitude. >> >> Later, we will probably offer a endpoint to update these properties. PUT >> /registry/device/{token} >> >> Sender >> Server >> Side >> >> We need to extend the current sender API to be able to add geolocation as >> a criteria. I see that as something like : >> >> { >> "message":{ >> "alert":"HELLO! >> }, >> "criteria":{ >> "geolocation": >> { >> "latitude" : 40.2566 >> "longitude": 2.36556 >> "within" : 5 >> "unit" : "Km" // optional, default is Km >> } >> } >> } >> >> >> In this example, the Push Notification will be sent only to devices >> within a radius of 5 km of the supplied location. >> >> On the implementation side, I think it make sense to use Hibernate Search >> since it has nice support forSpatial queries >> >> . >> >> Sender >> Client >> >> The different Sender Clients (Java, Node.js, .net) should be updated >> accordingly. >> Client >> SDKs >> >> In this fisrt iteration, the registration code would to be updated to >> include latitude and longitude for : >> >> - iOS (Including Safari ? ) >> - Android ( Including Chrome Apps ?) >> - JS UPS-SPS Lib >> - Cordova Plugin >> - Amazon >> - Windows >> >> Retrieving the current position of the device is not in scope of this >> first version, later we could offer some features around that. >> >> There are some jiras to track these tasks : >> https://issues.jboss.org/browse/AGPUSH-828 >> >> Comments and questions welcome ! >> >> Sebi >> >> >> _______________________________________________ >> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://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 listaerogear-dev at lists.jboss.orghttps://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 > -- 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/20141206/012330de/attachment.html From scm.blanc at gmail.com Sat Dec 6 07:14:59 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Sat, 6 Dec 2014 13:14:59 +0100 Subject: [aerogear-dev] [UPS] Geolocation Support In-Reply-To: References: <547C8D49.4050506@redhat.com> <547DD3C4.6010301@redhat.com> Message-ID: Envoy? de mon iPhone > Le 6 d?c. 2014 ? 12:09, Matthias Wessendorf a ?crit : > > > >> On Tue, Dec 2, 2014 at 2:59 PM, Summers Pittman wrote: >>> On 12/01/2014 10:57 AM, Sebastien Blanc wrote: >>> >>> >>>> On Mon, Dec 1, 2014 at 4:46 PM, Summers Pittman wrote: >>>> What other companies provide geofencing and what do their APIs look like? >>>> I know Google has some stuff for Android buried in Google Play Services. >>>> >>>> In general I think it might be less big brother if instead of the user reporting their location we add in metadata to filter incoming messages. This will have us sending more metadata but we don't have to worry about what if some bad guy compromises the server and start following his mother-in-law. >>> Sorry, I'm not sure to understand the alternative you propose. >> I don't like the push server knowing every user's location. > > it should know nothing. Instead, the geo data should be stored on a 'geo server' component. I'm working on that ;) , I hope to present a Poc next week > > -M > >> Instead of the push server deciding to send to a user based on her location the push server should send a "filter" property with the message the client can use to determine if it should show the message. >> >>> >>>> >>>> >>>> >>>> On 11/27/2014 11:52 AM, Sebastien Blanc wrote: >>>>> Hi Folks ! >>>>> >>>>> During our last f2f we agreed on adding some geolocation support for the next UnifiedPush Release (1.1). I would like to start here a thread to discuss this topic. >>>>> >>>>> Let's keep in mind : Crawl, Walk, Run >>>>> >>>>> I would like to start with a concrete proposition and initiate the discussions from there : >>>>> >>>>> Installations >>>>> >>>>> Model Change >>>>> >>>>> The idea is to add 2 new fields to the Installation Object : >>>>> >>>>> double longitude; >>>>> double latitude; >>>>> >>>>> These field should be optional ! >>>>> >>>>> Registration >>>>> >>>>> When the device registers, along with alias, categories etc ... it will also be possible to pass a latitude and longitude. >>>>> >>>>> Later, we will probably offer a endpoint to update these properties. PUT /registry/device/{token} >>>>> >>>>> Sender >>>>> >>>>> Server Side >>>>> >>>>> We need to extend the current sender API to be able to add geolocation as a criteria. I see that as something like : >>>>> >>>>> { >>>>> "message":{ >>>>> "alert":"HELLO! >>>>> }, >>>>> "criteria":{ >>>>> "geolocation": >>>>> { >>>>> "latitude" : 40.2566 >>>>> "longitude": 2.36556 >>>>> "within" : 5 >>>>> "unit" : "Km" // optional, default is Km >>>>> } >>>>> } >>>>> } >>>>> >>>>> In this example, the Push Notification will be sent only to devices within a radius of 5 km of the supplied location. >>>>> >>>>> On the implementation side, I think it make sense to use Hibernate Search since it has nice support forSpatial queries. >>>>> >>>>> Sender Client >>>>> >>>>> The different Sender Clients (Java, Node.js, .net) should be updated accordingly. >>>>> >>>>> Client SDKs >>>>> >>>>> In this fisrt iteration, the registration code would to be updated to include latitude and longitude for : >>>>> >>>>> iOS (Including Safari ? ) >>>>> Android ( Including Chrome Apps ?) >>>>> JS UPS-SPS Lib >>>>> Cordova Plugin >>>>> Amazon >>>>> Windows >>>>> Retrieving the current position of the device is not in scope of this first version, later we could offer some features around that. >>>>> >>>>> There are some jiras to track these tasks : https://issues.jboss.org/browse/AGPUSH-828 >>>>> >>>>> Comments and questions welcome ! >>>>> >>>>> Sebi >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> -- >> 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 > _______________________________________________ > 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/20141206/6c57b952/attachment-0001.html From daniel.bevenius at gmail.com Sun Dec 7 06:52:03 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Sun, 7 Dec 2014 12:52:03 +0100 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20141208 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141207/1fc13e08/attachment.html From edewit at redhat.com Mon Dec 8 03:31:54 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 08 Dec 2014 09:31:54 +0100 Subject: [aerogear-dev] Cordova Oauth2 plugin release Message-ID: <548561FA.6070100@redhat.com> Hi, We have released a new plugin for oauth2 version 1.0 this first version support google, keycloak and facebook as oauth providers for android and iOS. More to come stay tuned... Cheers, Erik Jan From bruno at abstractj.org Mon Dec 8 08:50:01 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 8 Dec 2014 11:50:01 -0200 Subject: [aerogear-dev] Unable to resolve realm public key remotely In-Reply-To: <1417184751354-10162.post@n5.nabble.com> References: <1417080090462-10134.post@n5.nabble.com> <1417081974138-10136.post@n5.nabble.com> <1417083773188-10138.post@n5.nabble.com> <1417084118889-10139.post@n5.nabble.com> <20141128140011.GA80824@abstractj.org> <1417184751354-10162.post@n5.nabble.com> Message-ID: <20141208135001.GA81216@abstractj.org> Good morning Amit, I think I see the problem here: WildFly configuration: - Copy & Paste (Option 1). Be aware that it will overrite your configuration files. 1. Download the configuration files from https://s3-eu-west-1.amazonaws.com/lucy.abstractj.org/configuration.tar.gz 2. cp configuration.tar.gz $JBOSS_HOME/ 3. tar xzvf configuration.tar.gz && rm configuration.tar.gz - Generating certificates (Option 2) 1. mkdir -p $JBOSS_HOME/standalone/configuration/certs 2. Download the shell script from https://raw.githubusercontent.com/aerogear/dockerfiles/master/wildfly/configuration/certs/certificate.sh. And adapt to your own needs. 3. cp configuration/certs/certificate.sh $JBOSS_HOME/standalone/configuration/certs 4. sudo ./certificate.sh 5. Edit standalone.xml like this: https://github.com/aerogear/dockerfiles/blob/master/wildfly/configuration/xml/standalone-sample.xml Test: https://localhost:8443 Deploying WildFly 8.1.0.Final: 1. Download https://github.com/aerogear/aerogear-unifiedpush-server/releases/download/1.0.2/aerogear-unifiedpush-server-1.0.2-dist.zip 2. unzip aerogear-unifiedpush-server-1.0.2-dist.zip && cd aerogear-unifiedpush-server-1.0.2-dist 3. cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments/ 4. cp servers/unifiedpush-auth-server.war $JBOSS_HOME/standalone/deployments 5. cp servers/unifiedpush-server-wildfly.war $JBOSS_HOME/standalone/deployments 6. On Chrome open a new Incognito window (to make sure you don't have any issues with cache) It must work otherwise, let us know. On 2014-11-28, Amit Ranjan wrote: > Hi Bruno, > > Thanks. I am uploading the files . > > I have tried both building the code that i downloaded from git: > https://github.com/aerogear/aerogear-unifiedpush-server.git > > and deploying the war files that I downloaded from: > https://github.com/aerogear/aerogear-simplepush-server/zipball/0.12.1 > > Wildfly server: > http://download.jboss.org/wildfly/8.1.0.Final/wildfly-8.1.0.Final.zip > > Thanks for your help. Aerogeardump.rar > > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Unable-to-resolve-realm-public-key-remotely-tp10134p10162.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 corinnekrych at gmail.com Mon Dec 8 09:42:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 8 Dec 2014 15:42:05 +0100 Subject: [aerogear-dev] iOS team meeting Message-ID: Hello Guys, Our iOS team meeting is scheduled for tomorrow usual time: http://oksoclap.com/p/aerogear-ios_team_meeting_9thDecember2014 ++ Corinne From cvasilak at gmail.com Mon Dec 8 10:16:18 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 8 Dec 2014 17:16:18 +0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: <7F45DC94-0E1B-4475-911C-B73CF47A269C@gmail.com> fyi, meeting minutes: Meeting ended Mon Dec 8 15:14:54 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-12-08-15.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-08-15.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-08-15.00.log.html On Dec 7, 2014, at 1:52 PM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20141208 > _______________________________________________ > 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/20141208/5f25c292/attachment.html From daniel at passos.me Mon Dec 8 10:59:29 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 8 Dec 2014 13:59:29 -0200 Subject: [aerogear-dev] Travis-ci and CloudBees problems on Android land Message-ID: Hi All, The Android team has been working on resolving a travis build issue last week (and part of weekend) with travis-ci[1][2]. I has been testing with proting the build to cloudbees[3][4]. travis-ci: In Travis the VM is running out of memory and getting killed. We fixed this by starting the emulator after compiling and I was able to make it pass 2 times[5][6], but when a PR[7] for AG was sent, we were back to the old problem[8] (travis-ci killed our build, because it's using a lot of memory) CloudBees: We are having trouble running the emulator[9] on CloudBees ([android] Emulator did not appear to start; giving up). We found a fix[10] but are not sure if we can apply it on CloudBees [1] https://travis-ci.org/danielpassos/aerogear-android-security/builds [2] https://travis-ci.org/secondsun/aerogear-android-security/builds [3] https://aerogear.ci.cloudbees.com/job/aerogear-android-security [4] https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe [5] https://travis-ci.org/danielpassos/aerogear-android-security/builds/43219446 [6] https://travis-ci.org/danielpassos/aerogear-android-security/builds/43256877 [7] https://github.com/aerogear/aerogear-android-security/pull/17 [8] https://travis-ci.org/aerogear/aerogear-android-security/builds/43295194 [9] https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe/6/jdk=openjdk8/console [10]: http://stackoverflow.com/questions/19349222/jenkins-android-emulator-emulator-did-not-appear-to-start-giving-up -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141208/0ba18787/attachment.html From supittma at redhat.com Mon Dec 8 11:02:08 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 08 Dec 2014 11:02:08 -0500 Subject: [aerogear-dev] Android 2.0.0 Release and Travis Message-ID: <5485CB80.7080703@redhat.com> As we mentioned in the meeting, we are having some blocking issues with Travis and the build. Basically running the emulator and the build uses more than 3 GiB of memory that we get from the VM and it gets killed. Passos and I are trying to refactor the build to get around this but it is still being difficult. In the meanwhile, dev must still go on (we've lost most of a week on this issue). We would like to shift the focus from fixing Travis to getting our docs finalized and publishing a RC of AGDROID. The only difference between the RC and Final will be reliable continuous integration. Wdyt? -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From matzew at apache.org Mon Dec 8 11:04:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 8 Dec 2014 17:04:48 +0100 Subject: [aerogear-dev] UnifiedPush-java-client 1.1.0-alpha.1 release In-Reply-To: References: Message-ID: had no time to test, since out if office But I am fine w/ shipping the first alpha. In wordt case an alpha.2 is cheap ;) On Wednesday, December 3, 2014, Sebastien Blanc wrote: > Hi folk, > > Following the UPS alpha.1 release, we have also staged a Java Sender > 1.1.0-alpha.1. > > Along some bug fixes, we have : > > - Support for the new Sender Message format. > - Builder API has been polished. > - Push Configuration can be externalized in a json file. > > > the staging repo is : > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4405 > > > Please test and vote ! > > Sebi > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141208/8fd748ce/attachment-0001.html From bruno at abstractj.org Mon Dec 8 12:10:56 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 8 Dec 2014 15:10:56 -0200 Subject: [aerogear-dev] Android 2.0.0 Release and Travis In-Reply-To: <5485CB80.7080703@redhat.com> References: <5485CB80.7080703@redhat.com> Message-ID: +1 On Mon, Dec 8, 2014 at 2:02 PM, Summers Pittman wrote: > As we mentioned in the meeting, we are having some blocking issues with > Travis and the build. Basically running the emulator and the build uses > more than 3 GiB of memory that we get from the VM and it gets killed. > Passos and I are trying to refactor the build to get around this but it > is still being difficult. > > In the meanwhile, dev must still go on (we've lost most of a week on > this issue). We would like to shift the focus from fixing Travis to > getting our docs finalized and publishing a RC of AGDROID. The only > difference between the RC and Final will be reliable continuous > integration. > > Wdyt? > > -- > 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141208/e2ead5dc/attachment.html From qmx at qmx.me Mon Dec 8 12:49:43 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 8 Dec 2014 15:49:43 -0200 Subject: [aerogear-dev] Android 2.0.0 Release and Travis In-Reply-To: <5485CB80.7080703@redhat.com> References: <5485CB80.7080703@redhat.com> Message-ID: <20141208174943.GE86965@darkstar.local> On Mon, Dec 08, 2014 at 11:02:08AM -0500, Summers Pittman wrote: > In the meanwhile, dev must still go on (we've lost most of a week on > this issue). We would like to shift the focus from fixing Travis to > getting our docs finalized and publishing a RC of AGDROID. The only > difference between the RC and Final will be reliable continuous integration. > > Wdyt? +9001 -- qmx From matzew at apache.org Mon Dec 8 13:20:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 8 Dec 2014 19:20:43 +0100 Subject: [aerogear-dev] Android 2.0.0 Release and Travis In-Reply-To: <5485CB80.7080703@redhat.com> References: <5485CB80.7080703@redhat.com> Message-ID: On Mon, Dec 8, 2014 at 5:02 PM, Summers Pittman wrote: > As we mentioned in the meeting, we are having some blocking issues with > Travis and the build. Basically running the emulator and the build uses > more than 3 GiB of memory that we get from the VM and it gets killed. > Passos and I are trying to refactor the build to get around this but it > is still being difficult. > > In the meanwhile, dev must still go on (we've lost most of a week on > this issue). wow, that's bad. > We would like to shift the focus from fixing Travis to > getting our docs finalized and publishing a RC of AGDROID. The only > difference between the RC and Final will be reliable continuous > integration. > +1 sounds like a good plan. If Jenkins is easy to setup, why not that. I think whatever works best for the Android team is the option to go -M > > Wdyt? > > -- > 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/20141208/7edcbf46/attachment.html From bruno at abstractj.org Mon Dec 8 16:24:32 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 8 Dec 2014 19:24:32 -0200 Subject: [aerogear-dev] Vote - Security roadmap priorities Message-ID: <20141208212432.GA3101@abstractj.org> Good morning, I updated the security roadmap with some ideas which I have in mind to be developed on the next year. Santa will be busy next year, so be ready to prioritize your wishlist. https://github.com/aerogear/aerogear.org/pull/440 Please comment on that PR with what are your top priorites for security on the next year. More ideas are always welcome, but let's prioritize. -- abstractj PGP: 0x84DC9914 From cvasilak at gmail.com Tue Dec 9 02:47:50 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 9 Dec 2014 09:47:50 +0200 Subject: [aerogear-dev] Android 2.0.0 Release and Travis In-Reply-To: <5485CB80.7080703@redhat.com> References: <5485CB80.7080703@redhat.com> Message-ID: <39B552E6-5E15-40E8-BF89-848F09DD68ED@gmail.com> +1 - Christos On Dec 8, 2014, at 6:02 PM, Summers Pittman wrote: > As we mentioned in the meeting, we are having some blocking issues with > Travis and the build. Basically running the emulator and the build uses > more than 3 GiB of memory that we get from the VM and it gets killed. > Passos and I are trying to refactor the build to get around this but it > is still being difficult. > > In the meanwhile, dev must still go on (we've lost most of a week on > this issue). We would like to shift the focus from fixing Travis to > getting our docs finalized and publishing a RC of AGDROID. The only > difference between the RC and Final will be reliable continuous integration. > > Wdyt? > > -- > 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 cvasilak at gmail.com Tue Dec 9 02:50:36 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 9 Dec 2014 09:50:36 +0200 Subject: [aerogear-dev] UnifiedPush-java-client 1.1.0-alpha.1 release In-Reply-To: References: Message-ID: used the new sender api on a PR[1] on quickstarts to test the UPS release and worked fine on me +1 1] https://github.com/aerogear/aerogear-push-quickstarts/pull/120 - Christos On Dec 3, 2014, at 11:36 AM, Sebastien Blanc wrote: > Hi folk, > > Following the UPS alpha.1 release, we have also staged a Java Sender 1.1.0-alpha.1. > > Along some bug fixes, we have : > > - Support for the new Sender Message format. > - Builder API has been polished. > - Push Configuration can be externalized in a json file. > > > the staging repo is : > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4405 > > > Please test and vote ! > > 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/20141209/99fe4ba8/attachment.html From scm.blanc at gmail.com Tue Dec 9 02:58:49 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 9 Dec 2014 08:58:49 +0100 Subject: [aerogear-dev] UnifiedPush-java-client 1.1.0-alpha.1 release In-Reply-To: References: Message-ID: Thx all ! The button has been pressed. It should be available on Maven Central by tomorrow ! Sebi On Tue, Dec 9, 2014 at 8:50 AM, Christos Vasilakis wrote: > used the new sender api on a PR[1] on quickstarts to test the UPS release > and worked fine on me +1 > > > 1] https://github.com/aerogear/aerogear-push-quickstarts/pull/120 > > > - > Christos > > > On Dec 3, 2014, at 11:36 AM, Sebastien Blanc wrote: > > Hi folk, > > Following the UPS alpha.1 release, we have also staged a Java Sender > 1.1.0-alpha.1. > > Along some bug fixes, we have : > > - Support for the new Sender Message format. > - Builder API has been polished. > - Push Configuration can be externalized in a json file. > > > the staging repo is : > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-4405 > > > Please test and vote ! > > 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/20141209/21b90ce5/attachment-0001.html From matzew at apache.org Tue Dec 9 04:47:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 9 Dec 2014 10:47:53 +0100 Subject: [aerogear-dev] AGPUSH-1075 / Automatic DB Migrations In-Reply-To: <20141201141254.GC67678@abstractj.org> References: <20141201134926.GR1912@darkstar.local> <20141201141254.GC67678@abstractj.org> Message-ID: FYI, Erik Jan's PR has been canceled. He agrees with qmx. On Mon, Dec 1, 2014 at 3:12 PM, Bruno Oliveira wrote: > Fair enough. I think it should be optional which makes me think about a > configuration page for UPS. > > On 2014-12-01, Douglas Campos wrote: > > Howdy! > > > > I was looking at Erik's PR[1] and was wondering about the implications > > of automatic DB migrations during app startup. I've got a lot of burns > > from this in the past, including: > > > > - DDL statements being disabled in production > > - Massive lock on a DB during an accidental restart which triggered the > > changes to happen > > - failed migration which ended up with the app having a model mismatch. > > > > I love migrations, I'm just throwing this here to make sure we're aware > > of the potential problems that incur with us running them automagically > > during app startup. > > > > Erik pointed out this shouldn't be a problem for openshift-like > > deployments, but what about the "enterprise" side of the house? > > > > Thoughts? > > > > [1]:https://github.com/aerogear/aerogear-unifiedpush-server/pull/448 > > > > -- > > 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/20141209/59fa11ef/attachment.html From matzew at apache.org Tue Dec 9 04:51:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 9 Dec 2014 10:51:59 +0100 Subject: [aerogear-dev] UPS: DB Migration - what's next ? Message-ID: Hi, we had some attempts for automatic migration, but the PR was closed based on a ML thread, where it was advised to not run auto migration. Now I think the next questions are: * Do we support a migration from 1.0.0.final to any new release of the 1.0.x series? * If yes, how do we do that, and where is the documentation for that? Does we need a new ticket (e.g. for documentation) to be included in the 1.0.3 release? -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/20141209/775d0e9e/attachment.html From matzew at apache.org Tue Dec 9 04:52:26 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 9 Dec 2014 10:52:26 +0100 Subject: [aerogear-dev] UPS: DB Migration - what's next ? In-Reply-To: References: Message-ID: oh, here is the old ticket, containing links to mentioned PR and ML thread https://issues.jboss.org/browse/AGPUSH-1130 -M On Tue, Dec 9, 2014 at 10:51 AM, Matthias Wessendorf wrote: > Hi, > > we had some attempts for automatic migration, but the PR was closed based > on a ML thread, where it was advised to not run auto migration. > > > Now I think the next questions are: > * Do we support a migration from 1.0.0.final to any new release of the > 1.0.x series? > * If yes, how do we do that, and where is the documentation for that? > > Does we need a new ticket (e.g. for documentation) to be included in the > 1.0.3 release? > > > > -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/20141209/32e98841/attachment.html From edewit at redhat.com Tue Dec 9 05:05:27 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 09 Dec 2014 11:05:27 +0100 Subject: [aerogear-dev] UPS: DB Migration - what's next ? In-Reply-To: References: Message-ID: <5486C967.50300@redhat.com> On 09/12/2014 10:51, Matthias Wessendorf wrote: > > Now I think the next questions are: > * Do we support a migration from 1.0.0.final to any new release of the > 1.0.x series? What would be the alternative? > * If yes, how do we do that, and where is the documentation for that? So yes, we have to have a migration path and of course it needs to be documented how to use it. From matzew at apache.org Tue Dec 9 05:29:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 9 Dec 2014 11:29:39 +0100 Subject: [aerogear-dev] UPS: DB Migration - what's next ? In-Reply-To: <5486C967.50300@redhat.com> References: <5486C967.50300@redhat.com> Message-ID: On Tue, Dec 9, 2014 at 11:05 AM, Erik Jan de Wit wrote: > > On 09/12/2014 10:51, Matthias Wessendorf wrote: > > > > Now I think the next questions are: > > * Do we support a migration from 1.0.0.final to any new release of the > > 1.0.x series? > What would be the alternative? > > * If yes, how do we do that, and where is the documentation for that? > So yes, we have to have a migration path and of course it needs to be > documented how to use it. > I looked here https://github.com/aerogear/aerogear-unifiedpush-server/tree/master/databases Is that all that is needed? > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141209/c070b444/attachment.html From cvasilak at gmail.com Tue Dec 9 06:06:59 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 9 Dec 2014 13:06:59 +0200 Subject: [aerogear-dev] iOS team meeting In-Reply-To: References: Message-ID: Hi all, Corinne is not feeling well today :( we postpone today?s meeting for tomorrow same time. - Christos On Dec 8, 2014, at 4:42 PM, Corinne Krych wrote: > Hello Guys, > > Our iOS team meeting is scheduled for tomorrow usual time: > http://oksoclap.com/p/aerogear-ios_team_meeting_9thDecember2014 > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Dec 9 06:21:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 9 Dec 2014 12:21:43 +0100 Subject: [aerogear-dev] [Aerogear-users] Cordova Oauth2 plugin release In-Reply-To: <548561FA.6070100@redhat.com> References: <548561FA.6070100@redhat.com> Message-ID: Nice! but let's have some 'heads-up' testing mail before next time ([1]). -Matthias [1] https://github.com/aerogear/collateral/wiki/Release-Process-(Cordova)#preparation On Mon, Dec 8, 2014 at 9:31 AM, Erik Jan de Wit wrote: > Hi, > > We have released a new plugin for oauth2 version 1.0 this first version > support google, keycloak and facebook as oauth providers for android and > iOS. More to come stay tuned... > > Cheers, > Erik Jan > _______________________________________________ > Aerogear-users mailing list > Aerogear-users at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users > -- 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/20141209/0815334b/attachment-0001.html From edewit at redhat.com Tue Dec 9 06:53:36 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 09 Dec 2014 12:53:36 +0100 Subject: [aerogear-dev] [Aerogear-users] Cordova Oauth2 plugin release In-Reply-To: References: <548561FA.6070100@redhat.com> Message-ID: <5486E2C0.2050907@redhat.com> As this is the first release there probably not a lot of people able to test this just yet. On 09/12/2014 12:21, Matthias Wessendorf wrote: > Nice! > > but let's have some 'heads-up' testing mail before next time ([1]). > > -Matthias > > [1] > https://github.com/aerogear/collateral/wiki/Release-Process-(Cordova)#preparation > > > On Mon, Dec 8, 2014 at 9:31 AM, Erik Jan de Wit > wrote: > > Hi, > > We have released a new plugin for oauth2 version 1.0 this first > version > support google, keycloak and facebook as oauth providers for > android and > iOS. More to come stay tuned... > > Cheers, > Erik Jan > _______________________________________________ > Aerogear-users mailing list > Aerogear-users at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users > > > > > -- > 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/20141209/219b1a86/attachment.html From matzew at apache.org Tue Dec 9 07:07:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 9 Dec 2014 13:07:05 +0100 Subject: [aerogear-dev] [Aerogear-users] Cordova Oauth2 plugin release In-Reply-To: <5486E2C0.2050907@redhat.com> References: <548561FA.6070100@redhat.com> <5486E2C0.2050907@redhat.com> Message-ID: IMO it would have still been worth to have a heads-up email. That one could have discussed the rational about skipping a vote/testing phase. Just saying. On Tue, Dec 9, 2014 at 12:53 PM, Erik Jan de Wit wrote: > As this is the first release there probably not a lot of people able to > test this just yet. > > > On 09/12/2014 12:21, Matthias Wessendorf wrote: > > Nice! > > but let's have some 'heads-up' testing mail before next time ([1]). > > -Matthias > > [1] > https://github.com/aerogear/collateral/wiki/Release-Process-(Cordova)#preparation > > On Mon, Dec 8, 2014 at 9:31 AM, Erik Jan de Wit wrote: > >> Hi, >> >> We have released a new plugin for oauth2 version 1.0 this first version >> support google, keycloak and facebook as oauth providers for android and >> iOS. More to come stay tuned... >> >> Cheers, >> Erik Jan >> _______________________________________________ >> Aerogear-users mailing list >> Aerogear-users at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-users >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.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/20141209/4f0ab3e2/attachment.html From edewit at redhat.com Tue Dec 9 07:32:08 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 09 Dec 2014 13:32:08 +0100 Subject: [aerogear-dev] [Aerogear-users] Cordova Oauth2 plugin release In-Reply-To: References: <548561FA.6070100@redhat.com> <5486E2C0.2050907@redhat.com> Message-ID: <5486EBC8.1020409@redhat.com> You mean a heads up mail to explain why there will be no heads up mail, well maybe next time On 09/12/2014 13:07, Matthias Wessendorf wrote: > IMO it would have still been worth to have a heads-up email. That one > could have discussed the rational about skipping a vote/testing phase. > Just saying. > > > On Tue, Dec 9, 2014 at 12:53 PM, Erik Jan de Wit > wrote: > > As this is the first release there probably not a lot of people > able to test this just yet. > > > On 09/12/2014 12:21, Matthias Wessendorf wrote: >> Nice! >> >> but let's have some 'heads-up' testing mail before next time ([1]). >> >> -Matthias >> >> [1] >> https://github.com/aerogear/collateral/wiki/Release-Process-(Cordova)#preparation >> >> >> On Mon, Dec 8, 2014 at 9:31 AM, Erik Jan de Wit >> > wrote: >> >> Hi, >> >> We have released a new plugin for oauth2 version 1.0 this >> first version >> support google, keycloak and facebook as oauth providers for >> android and >> iOS. More to come stay tuned... >> >> Cheers, >> Erik Jan >> _______________________________________________ >> Aerogear-users mailing list >> Aerogear-users at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-users >> >> >> >> >> -- >> 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/20141209/eab99fb9/attachment.html From bruno at abstractj.org Tue Dec 9 07:40:57 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 9 Dec 2014 10:40:57 -0200 Subject: [aerogear-dev] Agenda for the security meeting tomorrow Message-ID: <20141209124057.GA7217@abstractj.org> Good morning, this is the agenda for the meeting tomorrow: http://oksoclap.com/p/Yk6IhKpXZo. Feel free to add your items there, I know we have amazing stuff to include. Thanks in advance. -- abstractj PGP: 0x84DC9914 From matzew at apache.org Tue Dec 9 07:44:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 9 Dec 2014 13:44:19 +0100 Subject: [aerogear-dev] [Aerogear-users] Cordova Oauth2 plugin release In-Reply-To: <5486EBC8.1020409@redhat.com> References: <548561FA.6070100@redhat.com> <5486E2C0.2050907@redhat.com> <5486EBC8.1020409@redhat.com> Message-ID: On Tue, Dec 9, 2014 at 1:32 PM, Erik Jan de Wit wrote: > You mean a heads up mail to explain why there will be no heads up mail, > well maybe next time > Not at all. I think if the AeroGear project (that's all of us) is doing a release, it would be nice to _inform_ our larger community and ask for tests. Sharing is caring ;-) However, if (for whatever reason) we want to perform a direct release, with no heads-up to the community and no heads-up to potential testers etc, I _do_ think that needs to be discussed. There may or may not be valid reasons to it. It is nice to see that there is a release, no doubt. BUT in my opinion it would have been mandatory to have a heads up for the larger community. Again, sharing is caring. It could have been a casual message like "something is coming soon, if one cares, please test this branch/tag, if I hear nothing back in the next three days, I will move on". Messages like this are fundamental to an open development approach. -Matthias > > > On 09/12/2014 13:07, Matthias Wessendorf wrote: > > IMO it would have still been worth to have a heads-up email. That one > could have discussed the rational about skipping a vote/testing phase. Just > saying. > > > On Tue, Dec 9, 2014 at 12:53 PM, Erik Jan de Wit > wrote: > >> As this is the first release there probably not a lot of people able to >> test this just yet. >> >> >> On 09/12/2014 12:21, Matthias Wessendorf wrote: >> >> Nice! >> >> but let's have some 'heads-up' testing mail before next time ([1]). >> >> -Matthias >> >> [1] >> https://github.com/aerogear/collateral/wiki/Release-Process-(Cordova)#preparation >> >> On Mon, Dec 8, 2014 at 9:31 AM, Erik Jan de Wit >> wrote: >> >>> Hi, >>> >>> We have released a new plugin for oauth2 version 1.0 this first version >>> support google, keycloak and facebook as oauth providers for android and >>> iOS. More to come stay tuned... >>> >>> Cheers, >>> Erik Jan >>> _______________________________________________ >>> Aerogear-users mailing list >>> Aerogear-users at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-users >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.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 listaerogear-dev at lists.jboss.orghttps://lists.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/20141209/55674560/attachment.html From daniel at passos.me Tue Dec 9 10:21:32 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 9 Dec 2014 13:21:32 -0200 Subject: [aerogear-dev] UPS: DB Migration - what's next ? In-Reply-To: References: Message-ID: Answers in line On Tue, Dec 9, 2014 at 7:51 AM, Matthias Wessendorf wrote: > Hi, > > we had some attempts for automatic migration, but the PR was closed based > on a ML thread, where it was advised to not run auto migration. > > Now I think the next questions are: > * Do we support a migration from 1.0.0.final to any new release of the > 1.0.x series? > Yes! > * If yes, how do we do that, and where is the documentation for that? > * Release notes and link to migrate script. * ag.org page "How to migrate" > Does we need a new ticket (e.g. for documentation) to be included in the > 1.0.3 release? > > -Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141209/c0e6e165/attachment.html From matzew at apache.org Tue Dec 9 10:24:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 9 Dec 2014 16:24:27 +0100 Subject: [aerogear-dev] UPS: DB Migration - what's next ? In-Reply-To: References: Message-ID: On Tue, Dec 9, 2014 at 4:21 PM, Daniel Passos wrote: > Answers in line > > On Tue, Dec 9, 2014 at 7:51 AM, Matthias Wessendorf > wrote: > >> Hi, >> >> we had some attempts for automatic migration, but the PR was closed based >> on a ML thread, where it was advised to not run auto migration. >> >> Now I think the next questions are: >> * Do we support a migration from 1.0.0.final to any new release of the >> 1.0.x series? >> > > Yes! > > >> * If yes, how do we do that, and where is the documentation for that? >> > > * Release notes and link to migrate script. > oh, I was more asking if that is already available > * ag.org page "How to migrate" > > >> Does we need a new ticket (e.g. for documentation) to be included in the >> 1.0.3 release? >> >> -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/20141209/59692770/attachment.html From matzew at apache.org Tue Dec 9 10:29:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 9 Dec 2014 16:29:29 +0100 Subject: [aerogear-dev] Node.js / UPS Message-ID: Hi, I tried to build the 1.0.0.Final TAG, but I am getting: [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-admin-ui --- [INFO] Running 'npm install --color=false' in /Users/matzew/TEMP/CAT_IDs/admin-ui [INFO] npm WARN package.json ups-admin-ui at 0.0.0 No repository field. [INFO] [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-admin-ui --- [INFO] Running 'grunt dist --no-color' in /Users/matzew/TEMP/CAT_IDs/admin-ui [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? [INFO] [INFO] Running "bower:install" (bower) task [INFO] Fatal error: Unable to find suitable version for angular [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] Does the "Unable to find suitable version for angular" mean, we are no longer able to build the console? In worst case I could just comment out the module, on the root pom, and it would be included from my local (or remote) repo, but the actual message is a bit of a scary thing :-) -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/20141209/785c71ae/attachment-0001.html From lholmqui at redhat.com Tue Dec 9 10:33:20 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 9 Dec 2014 10:33:20 -0500 Subject: [aerogear-dev] Node.js / UPS In-Reply-To: References: Message-ID: <9FA96ADF-2B48-4487-AF09-F6EEE825A7AC@redhat.com> i had a similar thing, https://issues.jboss.org/browse/AGPUSH-951 , but couldn?t reproduce. i can try again with the 1.0.0.Final tag > On Dec 9, 2014, at 10:29 AM, Matthias Wessendorf wrote: > > Hi, > > I tried to build the 1.0.0.Final TAG, but I am getting: > > > [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-admin-ui --- > [INFO] Running 'npm install --color=false' in /Users/matzew/TEMP/CAT_IDs/admin-ui > [INFO] npm WARN package.json ups-admin-ui at 0.0.0 No repository field. > [INFO] > [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-admin-ui --- > [INFO] Running 'grunt dist --no-color' in /Users/matzew/TEMP/CAT_IDs/admin-ui > [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? > [INFO] > [INFO] Running "bower:install" (bower) task > [INFO] Fatal error: Unable to find suitable version for angular > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > > > Does the "Unable to find suitable version for angular" mean, we are no longer able to build the console? > > In worst case I could just comment out the module, on the root pom, and it would be included from my local (or remote) repo, but the actual message is a bit of a scary thing :-) > > > -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/20141209/f2e5e823/attachment.html From scm.blanc at gmail.com Tue Dec 9 11:06:48 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 9 Dec 2014 17:06:48 +0100 Subject: [aerogear-dev] Node.js / UPS In-Reply-To: References: Message-ID: Could you try with : https://github.com/aerogear/aerogear-unifiedpush-server#cleaning-the-admin-ui-build Sometimes I have to do that when switching between master and 1.0.x On Tue, Dec 9, 2014 at 4:29 PM, Matthias Wessendorf wrote: > Hi, > > I tried to build the 1.0.0.Final TAG, but I am getting: > > > [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ > unifiedpush-admin-ui --- > [INFO] Running 'npm install --color=false' in > /Users/matzew/TEMP/CAT_IDs/admin-ui > [INFO] npm WARN package.json ups-admin-ui at 0.0.0 No repository field. > [INFO] > [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ > unifiedpush-admin-ui --- > [INFO] Running 'grunt dist --no-color' in > /Users/matzew/TEMP/CAT_IDs/admin-ui > [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? > [INFO] > [INFO] Running "bower:install" (bower) task > [INFO] Fatal error: Unable to find suitable version for angular > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > > > Does the "Unable to find suitable version for angular" mean, we are no > longer able to build the console? > > In worst case I could just comment out the module, on the root pom, and it > would be included from my local (or remote) repo, but the actual message is > a bit of a scary thing :-) > > > -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/20141209/90169a64/attachment.html From agalante at redhat.com Tue Dec 9 11:55:13 2014 From: agalante at redhat.com (Andres Galante) Date: Tue, 9 Dec 2014 11:55:13 -0500 (EST) Subject: [aerogear-dev] Webpage js help In-Reply-To: <1781321288.748462.1418144015262.JavaMail.zimbra@redhat.com> Message-ID: <308562535.748684.1418144113581.JavaMail.zimbra@redhat.com> Hi! So far the web looks like this: http://andresgalante.com/aerogearwebsite/ I need help with a little js to keep the submenu in place. Do we have a resident js genius on the team that I can get for 20 mins? From lukas.fryc at gmail.com Wed Dec 10 03:24:28 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 10 Dec 2014 09:24:28 +0100 Subject: [aerogear-dev] Website color options In-Reply-To: <703691432.583995.1417816210853.JavaMail.zimbra@redhat.com> References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <5481BBA0.5050406@redhat.com> <1064347226.551934.1417790441529.JavaMail.zimbra@redhat.com> <5481C556.4040804@redhat.com> <1334793888.555017.1417791844810.JavaMail.zimbra@redhat.com> <703691432.583995.1417816210853.JavaMail.zimbra@redhat.com> Message-ID: It's just a Google Forms, I can create it, Andres! Should I use the current themes here? http://andresgalante.com/aerogearwebsite/colortest.html On Fri, Dec 5, 2014 at 10:50 PM, Andres Galante wrote: > Good idea, I would reduce the options to grey, logo blue or logo orange. > > Lukas how did you sent up the poll? > > > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "AeroGear Developer Mailing List" > Sent: Friday, December 5, 2014 5:51:20 PM > Subject: Re: [aerogear-dev] Website color options > > Also I would vote for creating a poll like Lukas did and tweet from > aerogears account. We did that for people vote for the name WildFly, why > not choose the colours of the website? > > > > On Fri, Dec 5, 2014 at 6:48 PM, Bruno Oliveira > wrote: > > > Red + Gray from my super personal taste. > > > > > > On Fri, Dec 5, 2014 at 6:20 PM, Corinne Krych > > wrote: > > > >> +1 with the blue from the logo > >> > >> ++ > >> Corinne > >> > On 05 Dec 2014, at 16:04, Andres Galante wrote: > >> > > >> > To be honest I don't think I am allow to change the logo :) Lets > >> continue with it as it is. > >> > > >> > > >> > > >> > ----- Original Message ----- > >> > From: "Erik Jan de Wit" > >> > To: "AeroGear Developer Mailing List" > >> > Sent: Friday, December 5, 2014 11:46:46 AM > >> > Subject: Re: [aerogear-dev] Website color options > >> > > >> > > >> > On 05/12/2014 15:40, Andres Galante wrote: > >> >> @erik I've reupload the images, should work now. > >> > Thanks > >> >> Thera are 2 versions of the website following the colors of the logo. > >> I like the blue one: > >> >> > >> >> http://andresgalante.com/aerogearwebsite/colortest.html > >> >> > >> >> The other options are test I did going bold on colors. Maybe we > should > >> narrow the choices on those first 2 (orange logo and blue logo) > >> > Right I like the blue of the logo as well > >> >> I must admit I am not a fan the logo, font choice is bad, type > >> treatment is wrong, icon is completely wrong, "G" is deformed, gears > >> centers are not centered, the braking on the height is absolutely wrong. > >> The colors of the logo have too little contrast to work either on dark > or > >> light backgrounds. But I guess this is a matter for another day. > >> > Hmm, right why not do that better as well, I see little sense in > picking > >> > a colour to match the logo now when we are going to change the logo > >> later. > >> >> > >> >> > >> >> > >> >> > >> >> ----- Original Message ----- > >> >> From: "Erik Jan de Wit" > >> >> To: "AeroGear Developer Mailing List" > >> >> Sent: Friday, December 5, 2014 11:05:20 AM > >> >> Subject: Re: [aerogear-dev] Website color options > >> >> > >> >> I like the green and the orange ( I have to like orange ;) ), but I > was > >> >> wondering are we going to change the colours of the logo as well? > Cause > >> >> the colors of the site are not the same they are harder. When we use > >> the > >> >> logo with the colours we have now will it not look dated? There also > >> >> seems that there are some missing images so maybe I'm missing > something > >> >> > >> >> On 04/12/2014 23:04, Andres Galante wrote: > >> >>> Blue and orange are the colors of the logo, gray is neutral, red is > >> the hat. > >> >> _______________________________________________ > >> >> aerogear-dev mailing list > >> >> aerogear-dev at lists.jboss.org > >> >> https://lists.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 > >> > > > > > > > > -- > > > > -- > > "The measure of a man is what he does with power" - Plato > > - > > @abstractj > > - > > Volenti Nihil Difficile > > > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141210/f7ea52d0/attachment-0001.html From lukas.fryc at gmail.com Wed Dec 10 03:30:13 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 10 Dec 2014 09:30:13 +0100 Subject: [aerogear-dev] Vote - Security roadmap priorities In-Reply-To: <20141208212432.GA3101@abstractj.org> References: <20141208212432.GA3101@abstractj.org> Message-ID: Thanks for bringing this up, Bruno, just copying from the PR to discuss here: "I would also add comprehensive platform specific docs for security concerns and (AeroGear) solutions with links to the external sources where possible/needed - that would be a big for our community." On Mon, Dec 8, 2014 at 10:24 PM, Bruno Oliveira wrote: > Good morning, I updated the security roadmap with some ideas which I > have in mind to be developed on the next year. Santa will be busy next > year, so be ready to prioritize your wishlist. > > https://github.com/aerogear/aerogear.org/pull/440 > > Please comment on that PR with what are your top priorites for security > on the next year. More ideas are always welcome, but let's prioritize. > > -- > > 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/20141210/ec4d71ea/attachment.html From lukas.fryc at gmail.com Wed Dec 10 03:44:17 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 10 Dec 2014 09:44:17 +0100 Subject: [aerogear-dev] Webpage js help In-Reply-To: <308562535.748684.1418144113581.JavaMail.zimbra@redhat.com> References: <1781321288.748462.1418144015262.JavaMail.zimbra@redhat.com> <308562535.748684.1418144113581.JavaMail.zimbra@redhat.com> Message-ID: Hey Andres, what do you exactly mean by keeping the submenu in place? Let's ping me on the IRC... On Tue, Dec 9, 2014 at 5:55 PM, Andres Galante wrote: > Hi! > So far the web looks like this: > http://andresgalante.com/aerogearwebsite/ > > I need help with a little js to keep the submenu in place. > Do we have a resident js genius on the team that I can get for 20 mins? > > _______________________________________________ > 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/20141210/5dc22ba6/attachment.html From bruno at abstractj.org Wed Dec 10 06:24:45 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Dec 2014 09:24:45 -0200 Subject: [aerogear-dev] Agenda for the security meeting tomorrow In-Reply-To: <20141209124057.GA7217@abstractj.org> References: <20141209124057.GA7217@abstractj.org> Message-ID: <20141210112445.GA12135@abstractj.org> Ahoy, we're planning our meeting for 30 minutes before than the time scheduled. Into this way everyone can join. Which means 14:30 UTC or 12:30 pm BRT (oh timezones) If you have any concerns, let me know. On 2014-12-09, Bruno Oliveira wrote: > Good morning, this is the agenda for the meeting tomorrow: > http://oksoclap.com/p/Yk6IhKpXZo. > > Feel free to add your items there, I know we have amazing stuff to > include. > > Thanks in advance. > > -- > > abstractj > PGP: 0x84DC9914 -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Wed Dec 10 06:28:32 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Dec 2014 09:28:32 -0200 Subject: [aerogear-dev] Vote - Security roadmap priorities In-Reply-To: References: <20141208212432.GA3101@abstractj.org> Message-ID: Aloha Lukas, I think documentation is part of our deliverables, it must be there. But could you please be more specific? What do you think is missing today? On Wed, Dec 10, 2014 at 6:30 AM, Luk?? Fry? wrote: > Thanks for bringing this up, Bruno, > > just copying from the PR to discuss here: > > "I would also add comprehensive platform specific docs for security > concerns and (AeroGear) solutions with links to the external sources where > possible/needed - that would be a big for our community." > > On Mon, Dec 8, 2014 at 10:24 PM, Bruno Oliveira > wrote: > >> Good morning, I updated the security roadmap with some ideas which I >> have in mind to be developed on the next year. Santa will be busy next >> year, so be ready to prioritize your wishlist. >> >> https://github.com/aerogear/aerogear.org/pull/440 >> >> Please comment on that PR with what are your top priorites for security >> on the next year. More ideas are always welcome, but let's prioritize. >> >> -- >> >> 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141210/a83c0acb/attachment.html From agalante at redhat.com Wed Dec 10 07:18:15 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 10 Dec 2014 07:18:15 -0500 (EST) Subject: [aerogear-dev] Webpage js help In-Reply-To: References: <1781321288.748462.1418144015262.JavaMail.zimbra@redhat.com> <308562535.748684.1418144113581.JavaMail.zimbra@redhat.com> Message-ID: <691715342.799890.1418213895843.JavaMail.zimbra@redhat.com> Thanks Lukas, it took me a lot of time, but I've solve it :) The website looks like this: http://andresgalante.com/aerogearwebsite/ If its ok with everyone, we can start integration with jekyll. Colors and style details can be change during integration or after. ----- Original Message ----- From: "Luk?? Fry?" To: "AeroGear Developer Mailing List" Sent: Wednesday, December 10, 2014 5:44:17 AM Subject: Re: [aerogear-dev] Webpage js help Hey Andres, what do you exactly mean by keeping the submenu in place? Let's ping me on the IRC... On Tue, Dec 9, 2014 at 5:55 PM, Andres Galante < agalante at redhat.com > wrote: Hi! So far the web looks like this: http://andresgalante.com/aerogearwebsite/ I need help with a little js to keep the submenu in place. Do we have a resident js genius on the team that I can get for 20 mins? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 agalante at redhat.com Wed Dec 10 07:20:57 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 10 Dec 2014 07:20:57 -0500 (EST) Subject: [aerogear-dev] Website color options In-Reply-To: References: <693715418.513129.1417726265763.JavaMail.zimbra@redhat.com> <5481C556.4040804@redhat.com> <1334793888.555017.1417791844810.JavaMail.zimbra@redhat.com> <703691432.583995.1417816210853.JavaMail.zimbra@redhat.com> Message-ID: <703268461.800042.1418214057115.JavaMail.zimbra@redhat.com> Yes please, you can use the current ones, just narrow them to blue and orange logo, and gray. I think that the others doesn't make much sense. The version I have online is the blue one. http://andresgalante.com/aerogearwebsite/ ----- Original Message ----- From: "Luk?? Fry?" To: "AeroGear Developer Mailing List" Sent: Wednesday, December 10, 2014 5:24:28 AM Subject: Re: [aerogear-dev] Website color options It's just a Google Forms, I can create it, Andres! Should I use the current themes here? http://andresgalante.com/aerogearwebsite/colortest.html On Fri, Dec 5, 2014 at 10:50 PM, Andres Galante < agalante at redhat.com > wrote: Good idea, I would reduce the options to grey, logo blue or logo orange. Lukas how did you sent up the poll? ----- Original Message ----- From: "Bruno Oliveira" < bruno at abstractj.org > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Friday, December 5, 2014 5:51:20 PM Subject: Re: [aerogear-dev] Website color options Also I would vote for creating a poll like Lukas did and tweet from aerogears account. We did that for people vote for the name WildFly, why not choose the colours of the website? On Fri, Dec 5, 2014 at 6:48 PM, Bruno Oliveira < bruno at abstractj.org > wrote: > Red + Gray from my super personal taste. > > > On Fri, Dec 5, 2014 at 6:20 PM, Corinne Krych < corinnekrych at gmail.com > > wrote: > >> +1 with the blue from the logo >> >> ++ >> Corinne >> > On 05 Dec 2014, at 16:04, Andres Galante < agalante at redhat.com > wrote: >> > >> > To be honest I don't think I am allow to change the logo :) Lets >> continue with it as it is. >> > >> > >> > >> > ----- Original Message ----- >> > From: "Erik Jan de Wit" < edewit at redhat.com > >> > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > >> > Sent: Friday, December 5, 2014 11:46:46 AM >> > Subject: Re: [aerogear-dev] Website color options >> > >> > >> > On 05/12/2014 15:40, Andres Galante wrote: >> >> @erik I've reupload the images, should work now. >> > Thanks >> >> Thera are 2 versions of the website following the colors of the logo. >> I like the blue one: >> >> >> >> http://andresgalante.com/aerogearwebsite/colortest.html >> >> >> >> The other options are test I did going bold on colors. Maybe we should >> narrow the choices on those first 2 (orange logo and blue logo) >> > Right I like the blue of the logo as well >> >> I must admit I am not a fan the logo, font choice is bad, type >> treatment is wrong, icon is completely wrong, "G" is deformed, gears >> centers are not centered, the braking on the height is absolutely wrong. >> The colors of the logo have too little contrast to work either on dark or >> light backgrounds. But I guess this is a matter for another day. >> > Hmm, right why not do that better as well, I see little sense in picking >> > a colour to match the logo now when we are going to change the logo >> later. >> >> >> >> >> >> >> >> >> >> ----- Original Message ----- >> >> From: "Erik Jan de Wit" < edewit at redhat.com > >> >> To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > >> >> Sent: Friday, December 5, 2014 11:05:20 AM >> >> Subject: Re: [aerogear-dev] Website color options >> >> >> >> I like the green and the orange ( I have to like orange ;) ), but I was >> >> wondering are we going to change the colours of the logo as well? Cause >> >> the colors of the site are not the same they are harder. When we use >> the >> >> logo with the colours we have now will it not look dated? There also >> >> seems that there are some missing images so maybe I'm missing something >> >> >> >> On 04/12/2014 23:04, Andres Galante wrote: >> >>> Blue and orange are the colors of the logo, gray is neutral, red is >> the hat. >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.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 >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 cvasilak at gmail.com Wed Dec 10 09:27:39 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 10 Dec 2014 16:27:39 +0200 Subject: [aerogear-dev] iOS team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Meeting ended Wed Dec 10 14:25:24 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-12-10-14.05.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-10-14.05.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-10-14.05.log.html On Dec 8, 2014, at 4:42 PM, Corinne Krych wrote: > Hello Guys, > > Our iOS team meeting is scheduled for tomorrow usual time: > http://oksoclap.com/p/aerogear-ios_team_meeting_9thDecember2014 > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From scm.blanc at gmail.com Wed Dec 10 09:48:05 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 10 Dec 2014 15:48:05 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server Message-ID: Hi all, I have been working on a POC around geolocation. Like we discussed in another thread, we decided not to have a "deep" integration with the Push server but instead a separate component / microservice. Well the POC is more a miniservice ;) So, the idea is to have a server to which devices can register by providing their positions. On the other side, the server provide an endpoint to make spatial queries, like give me all the installations within a radius of 10 km around this lat/ltg. Thanks to Forge, I created/scaffolded a really simple server providing the registration endpoint and the search endpoint. I tried to make a decent readme that will give you more details : https://github.com/sebastienblanc/unified-geo-server And as usual, I made a little screencast showing all that in action ;) https://www.youtube.com/watch?v=R-qdLJh4EWQ Please remember this is a POC, so the security is almost inexistant, the console is awful ;) What about the Client SDKs ? If we reach some kind of consensus arounf the concept of Unfied Geo Server we can start building the Client SDKs / POCs , they will be quite simple : retrieve geolocation and register to the geo endpoint. Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141210/828a7d4f/attachment.html From bruno at abstractj.org Wed Dec 10 10:01:43 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Dec 2014 13:01:43 -0200 Subject: [aerogear-dev] Agenda for the security meeting tomorrow In-Reply-To: <20141210112445.GA12135@abstractj.org> References: <20141209124057.GA7217@abstractj.org> <20141210112445.GA12135@abstractj.org> Message-ID: And the meeting minutes.... [13:00] ** Ending meeting. Generating minutes. Be patient :) [13:00] ** Meeting ended Wed Dec 10 14:59:57 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [13:00] ** Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-10-14.31.html [13:00] ** Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-10-14.31.txt On Wed, Dec 10, 2014 at 9:24 AM, Bruno Oliveira wrote: > Ahoy, we're planning our meeting for 30 minutes before than the time > scheduled. > Into this way everyone can join. > > Which means 14:30 UTC or 12:30 pm BRT (oh timezones) > > If you have any concerns, let me know. > > On 2014-12-09, Bruno Oliveira wrote: > > Good morning, this is the agenda for the meeting tomorrow: > > http://oksoclap.com/p/Yk6IhKpXZo. > > > > Feel free to add your items there, I know we have amazing stuff to > > include. > > > > Thanks in advance. > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > -- > > abstractj > PGP: 0x84DC9914 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141210/bd8aa7ca/attachment.html From edewit at redhat.com Wed Dec 10 10:23:15 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 10 Dec 2014 16:23:15 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: Message-ID: <54886563.2050902@redhat.com> Really nice, looks great already, one question how do I use the data from the geo search to send push notifications? From scm.blanc at gmail.com Wed Dec 10 10:28:43 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 10 Dec 2014 16:28:43 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: <54886563.2050902@redhat.com> References: <54886563.2050902@redhat.com> Message-ID: On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit wrote: > Really nice, looks great already, one question how do I use the data > from the geo search to send push notifications? > When the device registers to the geo server, it also provides an "alias". The idea is that the developer has to use the same "alias" when registering to the UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use these as criteria when sending a push notif to UPS. It tried to described that here : https://github.com/sebastienblanc/unified-geo-server#integration-with-push One idea for the alias, is to use the Keycloak (or whatever auth system) username as alias to have it somehow "unified" > > _______________________________________________ > 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/20141210/b229b22e/attachment.html From agalante at redhat.com Wed Dec 10 10:46:41 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 10 Dec 2014 10:46:41 -0500 (EST) Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: <54886563.2050902@redhat.com> Message-ID: <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> Nice work Sebastien! If you I can help with app or console design, please let me know. ----- Original Message ----- From: "Sebastien Blanc" To: "AeroGear Developer Mailing List" Sent: Wednesday, December 10, 2014 12:28:43 PM Subject: Re: [aerogear-dev] [POC] Unified Geo Server On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > wrote: Really nice, looks great already, one question how do I use the data from the geo search to send push notifications? When the device registers to the geo server, it also provides an "alias". The idea is that the developer has to use the same "alias" when registering to the UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use these as criteria when sending a push notif to UPS. It tried to described that here : https://github.com/sebastienblanc/unified-geo-server#integration-with-push One idea for the alias, is to use the Keycloak (or whatever auth system) username as alias to have it somehow "unified" _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 scm.blanc at gmail.com Wed Dec 10 11:12:02 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 10 Dec 2014 17:12:02 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> References: <54886563.2050902@redhat.com> <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante wrote: > Nice work Sebastien! > If you I can help with app or console design, please let me know. > Thanks ! A good strategy would probably to follow the Push Server and LiveOak (Angular/patternfly) model. > > ----- Original Message ----- > From: "Sebastien Blanc" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 10, 2014 12:28:43 PM > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > > > On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > > wrote: > > > Really nice, looks great already, one question how do I use the data > from the geo search to send push notifications? > When the device registers to the geo server, it also provides an "alias". > The idea is that the developer has to use the same "alias" when registering > to the UPS, then it's up to the backend app to retrieve the aliases for the > geoserver and use these as criteria when sending a push notif to UPS. > It tried to described that here : > https://github.com/sebastienblanc/unified-geo-server#integration-with-push > > One idea for the alias, is to use the Keycloak (or whatever auth system) > username as alias to have it somehow "unified" > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141210/a9909ddb/attachment-0001.html From lukas.fryc at gmail.com Wed Dec 10 12:23:01 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 10 Dec 2014 18:23:01 +0100 Subject: [aerogear-dev] Vote - Security roadmap priorities In-Reply-To: References: <20141208212432.GA3101@abstractj.org> Message-ID: That's fair, user guides should be a part of deliverables, :-) I'm just trying to envision what's going to be under AeroGearSecurity on http://andresgalante.com/aerogearwebsite/features.html Say I'm rather a newbie in the security land (which I am ;-), so I specifically would appreciate some kind of walk-through what are gotchas of iOS/Android/Cordova. IMO one of the projects goals should be also guide the users through the mine fields, teaching if you wish. Is it something we should think about or is it out of our scope? P.S.: this is not specific just to the security, but the original topic was, so I brought it here, because that's what I (as a user) would appreciate On Wed, Dec 10, 2014 at 12:28 PM, Bruno Oliveira wrote: > Aloha Lukas, I think documentation is part of our deliverables, it must be > there. But could you please be more specific? What do you think is missing > today? > > On Wed, Dec 10, 2014 at 6:30 AM, Luk?? Fry? wrote: > >> Thanks for bringing this up, Bruno, >> >> just copying from the PR to discuss here: >> >> "I would also add comprehensive platform specific docs for security >> concerns and (AeroGear) solutions with links to the external sources where >> possible/needed - that would be a big for our community." >> >> On Mon, Dec 8, 2014 at 10:24 PM, Bruno Oliveira >> wrote: >> >>> Good morning, I updated the security roadmap with some ideas which I >>> have in mind to be developed on the next year. Santa will be busy next >>> year, so be ready to prioritize your wishlist. >>> >>> https://github.com/aerogear/aerogear.org/pull/440 >>> >>> Please comment on that PR with what are your top priorites for security >>> on the next year. More ideas are always welcome, but let's prioritize. >>> >>> -- >>> >>> 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 >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > _______________________________________________ > 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/20141210/9ebe4721/attachment.html From bruno at abstractj.org Wed Dec 10 12:55:40 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Dec 2014 15:55:40 -0200 Subject: [aerogear-dev] Cordova and Windows phone pull requests Message-ID: <20141210175540.GA21864@abstractj.org> Good morning, today we have the following pull requests opened: 9 Dec 2014 08:29 AM - edewit - fix issue - https://github.com/aerogear/aerogear-pushplugin-cordova/pull/58 1 Dec 2014 13:26 PM - edewit - better error handling - https://github.com/aerogear/aerogear-pushplugin-cordova/pull/57 3 Dec 2014 14:00 PM - edewit - plugin result should contain password and salt - https://github.com/aerogear/aerogear-crypto-cordova/pull/6 3 Dec 2014 08:49 AM - edewit - removed jquery dependency - https://github.com/aerogear/aerogear-crypto-cordova/pull/4 9 Dec 2014 07:48 AM - edewit - ie does not support remove() - https://github.com/aerogear/aerogear-push-helloworld/pull/74 5 Dec 2014 20:23 PM - edewit - new ui - https://github.com/aerogear/aerogear-push-helloworld/pull/73 9 Dec 2014 08:27 AM - edewit - convert from event driven to task for Mpns and return device token - https://github.com/aerogear/aerogear-windows-push/pull/2 8 Dec 2014 14:50 PM - edewit - exception handling is something that the client should do - https://github.com/aerogear/aerogear-windows-push/pull/1 Would be nice if we got more people providing feedback on it. -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Wed Dec 10 13:06:16 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Dec 2014 16:06:16 -0200 Subject: [aerogear-dev] Vote - Security roadmap priorities In-Reply-To: References: <20141208212432.GA3101@abstractj.org> Message-ID: <20141210180616.GC21864@abstractj.org> I see, once security is more like a cross concern. I see on that page all the references to what we already did (only link pointing people to the right place). Also we can add more information if necessary, not sure which kind of guide would be helpful, but well, ideas are welcome. On 2014-12-10, Luk?? Fry? wrote: > That's fair, user guides should be a part of deliverables, :-) > > I'm just trying to envision what's going to be under AeroGearSecurity on > http://andresgalante.com/aerogearwebsite/features.html > > > Say I'm rather a newbie in the security land (which I am ;-), so I > specifically would appreciate some kind of walk-through what are gotchas of > iOS/Android/Cordova. > > IMO one of the projects goals should be also guide the users through the > mine fields, teaching if you wish. > > Is it something we should think about or is it out of our scope? > > > P.S.: this is not specific just to the security, but the original topic > was, so I brought it here, because that's what I (as a user) would > appreciate > > > On Wed, Dec 10, 2014 at 12:28 PM, Bruno Oliveira > wrote: > > > Aloha Lukas, I think documentation is part of our deliverables, it must be > > there. But could you please be more specific? What do you think is missing > > today? > > > > On Wed, Dec 10, 2014 at 6:30 AM, Luk?? Fry? wrote: > > > >> Thanks for bringing this up, Bruno, > >> > >> just copying from the PR to discuss here: > >> > >> "I would also add comprehensive platform specific docs for security > >> concerns and (AeroGear) solutions with links to the external sources where > >> possible/needed - that would be a big for our community." > >> > >> On Mon, Dec 8, 2014 at 10:24 PM, Bruno Oliveira > >> wrote: > >> > >>> Good morning, I updated the security roadmap with some ideas which I > >>> have in mind to be developed on the next year. Santa will be busy next > >>> year, so be ready to prioritize your wishlist. > >>> > >>> https://github.com/aerogear/aerogear.org/pull/440 > >>> > >>> Please comment on that PR with what are your top priorites for security > >>> on the next year. More ideas are always welcome, but let's prioritize. > >>> > >>> -- > >>> > >>> 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 > >> > > > > > > > > -- > > > > -- > > "The measure of a man is what he does with power" - Plato > > - > > @abstractj > > - > > Volenti Nihil Difficile > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.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 lukas.fryc at gmail.com Wed Dec 10 13:27:12 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 10 Dec 2014 19:27:12 +0100 Subject: [aerogear-dev] [Poll] AeroGear.org Web Site Color Test Message-ID: Hello good people, Andres came with nice colour sets for a new Aerogear.org site. We would like you to consider which one fits the project best or simply which is a best option in your eyes! See the the poll here: http://goo.gl/forms/4YojF0DMbi Cheers! ~ Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141210/72f56c9b/attachment.html From lukas.fryc at gmail.com Wed Dec 10 13:31:43 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 10 Dec 2014 19:31:43 +0100 Subject: [aerogear-dev] Vote - Security roadmap priorities In-Reply-To: <20141210180616.GC21864@abstractj.org> References: <20141208212432.GA3101@abstractj.org> <20141210180616.GC21864@abstractj.org> Message-ID: Yea, I believe we will gradually get there... adding it to the roadmap would can just help :-) On Wed, Dec 10, 2014 at 7:06 PM, Bruno Oliveira wrote: > > I see, once security is more like a cross concern. I see on that page > all the references to what we already did (only link pointing people to > the right place). Also we can add more information if necessary, not > sure which kind of guide would be helpful, but well, ideas are welcome. > > On 2014-12-10, Luk?? Fry? wrote: > > That's fair, user guides should be a part of deliverables, :-) > > > > I'm just trying to envision what's going to be under AeroGearSecurity on > > http://andresgalante.com/aerogearwebsite/features.html > > > > > > Say I'm rather a newbie in the security land (which I am ;-), so I > > specifically would appreciate some kind of walk-through what are gotchas > of > > iOS/Android/Cordova. > > > > IMO one of the projects goals should be also guide the users through the > > mine fields, teaching if you wish. > > > > Is it something we should think about or is it out of our scope? > > > > > > P.S.: this is not specific just to the security, but the original topic > > was, so I brought it here, because that's what I (as a user) would > > appreciate > > > > > > On Wed, Dec 10, 2014 at 12:28 PM, Bruno Oliveira > > wrote: > > > > > Aloha Lukas, I think documentation is part of our deliverables, it > must be > > > there. But could you please be more specific? What do you think is > missing > > > today? > > > > > > On Wed, Dec 10, 2014 at 6:30 AM, Luk?? Fry? > wrote: > > > > > >> Thanks for bringing this up, Bruno, > > >> > > >> just copying from the PR to discuss here: > > >> > > >> "I would also add comprehensive platform specific docs for security > > >> concerns and (AeroGear) solutions with links to the external sources > where > > >> possible/needed - that would be a big for our community." > > >> > > >> On Mon, Dec 8, 2014 at 10:24 PM, Bruno Oliveira > > >> wrote: > > >> > > >>> Good morning, I updated the security roadmap with some ideas which I > > >>> have in mind to be developed on the next year. Santa will be busy > next > > >>> year, so be ready to prioritize your wishlist. > > >>> > > >>> https://github.com/aerogear/aerogear.org/pull/440 > > >>> > > >>> Please comment on that PR with what are your top priorites for > security > > >>> on the next year. More ideas are always welcome, but let's > prioritize. > > >>> > > >>> -- > > >>> > > >>> 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 > > >> > > > > > > > > > > > > -- > > > > > > -- > > > "The measure of a man is what he does with power" - Plato > > > - > > > @abstractj > > > - > > > Volenti Nihil Difficile > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.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/20141210/4d0377d3/attachment-0001.html From lholmqui at redhat.com Wed Dec 10 14:20:15 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 10 Dec 2014 14:20:15 -0500 Subject: [aerogear-dev] [Aerogear-users] [Poll] AeroGear.org Web Site Color Test In-Reply-To: References: Message-ID: <700DA584-7D60-49DE-8F13-E9BD5D522CB0@redhat.com> i like the blue(color from the logo, voted for that one), but on the prototyped site, i think the yellow is to bright for the words, maybe the orange for the words? > On Dec 10, 2014, at 1:27 PM, Luk?? Fry? wrote: > > Hello good people, > > Andres came with nice colour sets for a new Aerogear.org site. > > We would like you to consider which one fits the project best or simply which is a best option in your eyes! > > See the the poll here: > > http://goo.gl/forms/4YojF0DMbi > > > Cheers! > > ~ Lukas > _______________________________________________ > Aerogear-users mailing list > Aerogear-users at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141210/458f964b/attachment.html From agalante at redhat.com Wed Dec 10 14:43:10 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 10 Dec 2014 14:43:10 -0500 (EST) Subject: [aerogear-dev] [Aerogear-users] [Poll] AeroGear.org Web Site Color Test In-Reply-To: <700DA584-7D60-49DE-8F13-E9BD5D522CB0@redhat.com> References: <700DA584-7D60-49DE-8F13-E9BD5D522CB0@redhat.com> Message-ID: <1060825076.835860.1418240590112.JavaMail.zimbra@redhat.com> Hi Lucas, The problem with color on the web is that you never know how the user monitor is calibrated and sometimes it does happened that yellows are too bright. Here are tests of different orange: https://dl.dropboxusercontent.com/u/4371641/orange.png https://dl.dropboxusercontent.com/u/4371641/orange2.png https://dl.dropboxusercontent.com/u/4371641/orange3.png And these are yellow test: https://dl.dropboxusercontent.com/u/4371641/yellow.png https://dl.dropboxusercontent.com/u/4371641/yellow2.png https://dl.dropboxusercontent.com/u/4371641/yellow3.png In my monitor yellow is much easier to read, but it's not bright. What do you think? ----- Original Message ----- From: "Lucas Holmquist" To: aerogear-users at lists.jboss.org Cc: "AeroGear Developer Mailing List" Sent: Wednesday, December 10, 2014 4:20:15 PM Subject: Re: [aerogear-dev] [Aerogear-users] [Poll] AeroGear.org Web Site Color Test i like the blue(color from the logo, voted for that one), but on the prototyped site, i think the yellow is to bright for the words, maybe the orange for the words? On Dec 10, 2014, at 1:27 PM, Luk?? Fry? < lukas.fryc at gmail.com > wrote: Hello good people, Andres came with nice colour sets for a new Aerogear.org site. We would like you to consider which one fits the project best or simply which is a best option in your eyes! See the the poll here: http://goo.gl/forms/4YojF0DMbi Cheers! ~ Lukas _______________________________________________ Aerogear-users mailing list Aerogear-users at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-users _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From agalante at redhat.com Wed Dec 10 14:54:24 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 10 Dec 2014 14:54:24 -0500 (EST) Subject: [aerogear-dev] [Aerogear-users] [Poll] AeroGear.org Web Site Color Test In-Reply-To: <700DA584-7D60-49DE-8F13-E9BD5D522CB0@redhat.com> References: <700DA584-7D60-49DE-8F13-E9BD5D522CB0@redhat.com> Message-ID: <1243248424.836778.1418241264918.JavaMail.zimbra@redhat.com> ...and the orange from the logo just doesn't have enough contrast, these are test with the exact same color of the logo, the logo from the inner "G" gear and an even lighter version of the same color: https://dl.dropboxusercontent.com/u/4371641/logo-color.png https://dl.dropboxusercontent.com/u/4371641/logo-color2.png https://dl.dropboxusercontent.com/u/4371641/logo-color3.png Is not even orange... is a kind of pinkish salmon color :p ----- Original Message ----- From: "Lucas Holmquist" To: aerogear-users at lists.jboss.org Cc: "AeroGear Developer Mailing List" Sent: Wednesday, December 10, 2014 4:20:15 PM Subject: Re: [aerogear-dev] [Aerogear-users] [Poll] AeroGear.org Web Site Color Test i like the blue(color from the logo, voted for that one), but on the prototyped site, i think the yellow is to bright for the words, maybe the orange for the words? On Dec 10, 2014, at 1:27 PM, Luk?? Fry? < lukas.fryc at gmail.com > wrote: Hello good people, Andres came with nice colour sets for a new Aerogear.org site. We would like you to consider which one fits the project best or simply which is a best option in your eyes! See the the poll here: http://goo.gl/forms/4YojF0DMbi Cheers! ~ Lukas _______________________________________________ Aerogear-users mailing list Aerogear-users at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-users _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Wed Dec 10 14:55:56 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 10 Dec 2014 20:55:56 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: <54886563.2050902@redhat.com> <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> Message-ID: Nice POC indeed, it makes things more concrete. Looking at the the similar process for UGS and UPS and thinking we might need similar mini/micro services, I think eventually we will benefit having a form of aggregator where you say: create an app for UPS with plugin UGS, under the cover, 2 app ids are created and unified with one appId + a map of corresponding app ids. With the same idea some of the admin console for creating app could be mutualised. This is more a ?for the future? improvement and does not interfere with your POC. ++ Corinne > On 10 Dec 2014, at 17:12, Sebastien Blanc wrote: > > > > On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante wrote: > Nice work Sebastien! > If you I can help with app or console design, please let me know. > Thanks ! A good strategy would probably to follow the Push Server and LiveOak (Angular/patternfly) model. > > ----- Original Message ----- > From: "Sebastien Blanc" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 10, 2014 12:28:43 PM > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > > > On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > wrote: > > > Really nice, looks great already, one question how do I use the data > from the geo search to send push notifications? > When the device registers to the geo server, it also provides an "alias". The idea is that the developer has to use the same "alias" when registering to the UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use these as criteria when sending a push notif to UPS. > It tried to described that here : https://github.com/sebastienblanc/unified-geo-server#integration-with-push > > One idea for the alias, is to use the Keycloak (or whatever auth system) username as alias to have it somehow "unified" > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 agalante at redhat.com Wed Dec 10 15:04:51 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 10 Dec 2014 15:04:51 -0500 (EST) Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: <54886563.2050902@redhat.com> <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> Message-ID: <1404943696.837339.1418241891351.JavaMail.zimbra@redhat.com> +1 We are thinking of this kind of scenarios for the next step on the console UI. The way we have the navigation now it is not flexible enough. Hopefully I'll have updates on console UX to share with you soon :) ----- Original Message ----- From: "Corinne Krych" To: "AeroGear Developer Mailing List" Sent: Wednesday, December 10, 2014 4:55:56 PM Subject: Re: [aerogear-dev] [POC] Unified Geo Server Nice POC indeed, it makes things more concrete. Looking at the the similar process for UGS and UPS and thinking we might need similar mini/micro services, I think eventually we will benefit having a form of aggregator where you say: create an app for UPS with plugin UGS, under the cover, 2 app ids are created and unified with one appId + a map of corresponding app ids. With the same idea some of the admin console for creating app could be mutualised. This is more a ?for the future? improvement and does not interfere with your POC. ++ Corinne > On 10 Dec 2014, at 17:12, Sebastien Blanc wrote: > > > > On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante wrote: > Nice work Sebastien! > If you I can help with app or console design, please let me know. > Thanks ! A good strategy would probably to follow the Push Server and LiveOak (Angular/patternfly) model. > > ----- Original Message ----- > From: "Sebastien Blanc" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 10, 2014 12:28:43 PM > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > > > On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > wrote: > > > Really nice, looks great already, one question how do I use the data > from the geo search to send push notifications? > When the device registers to the geo server, it also provides an "alias". The idea is that the developer has to use the same "alias" when registering to the UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use these as criteria when sending a push notif to UPS. > It tried to described that here : https://github.com/sebastienblanc/unified-geo-server#integration-with-push > > One idea for the alias, is to use the Keycloak (or whatever auth system) username as alias to have it somehow "unified" > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 From scm.blanc at gmail.com Wed Dec 10 15:23:51 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Wed, 10 Dec 2014 21:23:51 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: <54886563.2050902@redhat.com> <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> Message-ID: <26F12C4F-7E10-4AEC-AC22-E48A774EBDFF@gmail.com> Envoy? de mon iPhone > Le 10 d?c. 2014 ? 20:55, Corinne Krych a ?crit : > > Nice POC indeed, it makes things more concrete. > > Looking at the the similar process for UGS and UPS and thinking we might need similar mini/micro services, I think eventually we will benefit having a form of aggregator where you say: create an app for UPS with plugin UGS, under the cover, 2 app ids are created and unified with one appId + a map of corresponding app ids. > With the same idea some of the admin console for creating app could be mutualised. Make totally sense and I have also been thinking about that. My first thoughts would be something's around fabric8/fuse and using amq. One concrete example that I will try to add to the POC is sending a message on a amq channel when a device registers. Other apps could consume this queue. That might be a start. > > This is more a ?for the future? improvement and does not interfere with your POC. > > ++ > Corinne > >> On 10 Dec 2014, at 17:12, Sebastien Blanc wrote: >> >> >> >> On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante wrote: >> Nice work Sebastien! >> If you I can help with app or console design, please let me know. >> Thanks ! A good strategy would probably to follow the Push Server and LiveOak (Angular/patternfly) model. >> >> ----- Original Message ----- >> From: "Sebastien Blanc" >> To: "AeroGear Developer Mailing List" >> Sent: Wednesday, December 10, 2014 12:28:43 PM >> Subject: Re: [aerogear-dev] [POC] Unified Geo Server >> >> >> >> On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > wrote: >> >> >> Really nice, looks great already, one question how do I use the data >> from the geo search to send push notifications? >> When the device registers to the geo server, it also provides an "alias". The idea is that the developer has to use the same "alias" when registering to the UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use these as criteria when sending a push notif to UPS. >> It tried to described that here : https://github.com/sebastienblanc/unified-geo-server#integration-with-push >> >> One idea for the alias, is to use the Keycloak (or whatever auth system) username as alias to have it somehow "unified" >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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 From bruno at abstractj.org Wed Dec 10 15:31:26 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Dec 2014 18:31:26 -0200 Subject: [aerogear-dev] Vote - Security roadmap priorities In-Reply-To: References: <20141208212432.GA3101@abstractj.org> <20141210180616.GC21864@abstractj.org> Message-ID: <20141210203126.GB22566@abstractj.org> Sure why not? What would like to see added? "docs for security concerns and (AeroGear) solutions" is a bit generic, but I'm fine if the team is on the same page. Regarding "demos". What would you like to see? Currently we have demos for OAuth2, some for crypto and OTP. What's missing? On 2014-12-10, Luk?? Fry? wrote: > Yea, I believe we will gradually get there... adding it to the roadmap > would can just help :-) > > On Wed, Dec 10, 2014 at 7:06 PM, Bruno Oliveira wrote: > > > > > I see, once security is more like a cross concern. I see on that page > > all the references to what we already did (only link pointing people to > > the right place). Also we can add more information if necessary, not > > sure which kind of guide would be helpful, but well, ideas are welcome. > > > > On 2014-12-10, Luk?? Fry? wrote: > > > That's fair, user guides should be a part of deliverables, :-) > > > > > > I'm just trying to envision what's going to be under AeroGearSecurity on > > > http://andresgalante.com/aerogearwebsite/features.html > > > > > > > > > Say I'm rather a newbie in the security land (which I am ;-), so I > > > specifically would appreciate some kind of walk-through what are gotchas > > of > > > iOS/Android/Cordova. > > > > > > IMO one of the projects goals should be also guide the users through the > > > mine fields, teaching if you wish. > > > > > > Is it something we should think about or is it out of our scope? > > > > > > > > > P.S.: this is not specific just to the security, but the original topic > > > was, so I brought it here, because that's what I (as a user) would > > > appreciate > > > > > > > > > On Wed, Dec 10, 2014 at 12:28 PM, Bruno Oliveira > > > wrote: > > > > > > > Aloha Lukas, I think documentation is part of our deliverables, it > > must be > > > > there. But could you please be more specific? What do you think is > > missing > > > > today? > > > > > > > > On Wed, Dec 10, 2014 at 6:30 AM, Luk?? Fry? > > wrote: > > > > > > > >> Thanks for bringing this up, Bruno, > > > >> > > > >> just copying from the PR to discuss here: > > > >> > > > >> "I would also add comprehensive platform specific docs for security > > > >> concerns and (AeroGear) solutions with links to the external sources > > where > > > >> possible/needed - that would be a big for our community." > > > >> > > > >> On Mon, Dec 8, 2014 at 10:24 PM, Bruno Oliveira > > > >> wrote: > > > >> > > > >>> Good morning, I updated the security roadmap with some ideas which I > > > >>> have in mind to be developed on the next year. Santa will be busy > > next > > > >>> year, so be ready to prioritize your wishlist. > > > >>> > > > >>> https://github.com/aerogear/aerogear.org/pull/440 > > > >>> > > > >>> Please comment on that PR with what are your top priorites for > > security > > > >>> on the next year. More ideas are always welcome, but let's > > prioritize. > > > >>> > > > >>> -- > > > >>> > > > >>> 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 > > > >> > > > > > > > > > > > > > > > > -- > > > > > > > > -- > > > > "The measure of a man is what he does with power" - Plato > > > > - > > > > @abstractj > > > > - > > > > Volenti Nihil Difficile > > > > > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.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 daniel.bevenius at gmail.com Thu Dec 11 02:31:07 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 11 Dec 2014 08:31:07 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: <26F12C4F-7E10-4AEC-AC22-E48A774EBDFF@gmail.com> References: <54886563.2050902@redhat.com> <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> <26F12C4F-7E10-4AEC-AC22-E48A774EBDFF@gmail.com> Message-ID: Thanks for the screencast! On 10 December 2014 at 21:23, S?bastien Blanc wrote: > > > Envoy? de mon iPhone > > > Le 10 d?c. 2014 ? 20:55, Corinne Krych a ?crit > : > > > > Nice POC indeed, it makes things more concrete. > > > > Looking at the the similar process for UGS and UPS and thinking we might > need similar mini/micro services, I think eventually we will benefit having > a form of aggregator where you say: create an app for UPS with plugin UGS, > under the cover, 2 app ids are created and unified with one appId + a map > of corresponding app ids. > > With the same idea some of the admin console for creating app could be > mutualised. > Make totally sense and I have also been thinking about that. > My first thoughts would be something's around fabric8/fuse and using amq. > One concrete example that I will try to add to the POC is sending a > message on a amq channel when a device registers. Other apps could consume > this queue. That might be a start. > > > > This is more a ?for the future? improvement and does not interfere with > your POC. > > > > ++ > > Corinne > > > >> On 10 Dec 2014, at 17:12, Sebastien Blanc wrote: > >> > >> > >> > >> On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante > wrote: > >> Nice work Sebastien! > >> If you I can help with app or console design, please let me know. > >> Thanks ! A good strategy would probably to follow the Push Server and > LiveOak (Angular/patternfly) model. > >> > >> ----- Original Message ----- > >> From: "Sebastien Blanc" > >> To: "AeroGear Developer Mailing List" > >> Sent: Wednesday, December 10, 2014 12:28:43 PM > >> Subject: Re: [aerogear-dev] [POC] Unified Geo Server > >> > >> > >> > >> On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > > wrote: > >> > >> > >> Really nice, looks great already, one question how do I use the data > >> from the geo search to send push notifications? > >> When the device registers to the geo server, it also provides an > "alias". The idea is that the developer has to use the same "alias" when > registering to the UPS, then it's up to the backend app to retrieve the > aliases for the geoserver and use these as criteria when sending a push > notif to UPS. > >> It tried to described that here : > https://github.com/sebastienblanc/unified-geo-server#integration-with-push > >> > >> One idea for the alias, is to use the Keycloak (or whatever auth > system) username as alias to have it somehow "unified" > >> > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.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/20141211/9cebdef5/attachment.html From edewit at redhat.com Thu Dec 11 02:18:51 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 11 Dec 2014 08:18:51 +0100 Subject: [aerogear-dev] [Aerogear-users] [Poll] AeroGear.org Web Site Color Test In-Reply-To: <1060825076.835860.1418240590112.JavaMail.zimbra@redhat.com> References: <700DA584-7D60-49DE-8F13-E9BD5D522CB0@redhat.com> <1060825076.835860.1418240590112.JavaMail.zimbra@redhat.com> Message-ID: <5489455B.2040102@redhat.com> I like orange3 On 10/12/2014 20:43, Andres Galante wrote: > Hi Lucas, > > The problem with color on the web is that you never know how the user monitor is calibrated and sometimes it does happened that yellows are too bright. > > Here are tests of different orange: > https://dl.dropboxusercontent.com/u/4371641/orange.png > https://dl.dropboxusercontent.com/u/4371641/orange2.png > https://dl.dropboxusercontent.com/u/4371641/orange3.png > > And these are yellow test: > https://dl.dropboxusercontent.com/u/4371641/yellow.png > https://dl.dropboxusercontent.com/u/4371641/yellow2.png > https://dl.dropboxusercontent.com/u/4371641/yellow3.png > > In my monitor yellow is much easier to read, but it's not bright. > > What do you think? > > > ----- Original Message ----- > From: "Lucas Holmquist" > To: aerogear-users at lists.jboss.org > Cc: "AeroGear Developer Mailing List" > Sent: Wednesday, December 10, 2014 4:20:15 PM > Subject: Re: [aerogear-dev] [Aerogear-users] [Poll] AeroGear.org Web Site Color Test > > i like the blue(color from the logo, voted for that one), but on the prototyped site, i think the yellow is to bright for the words, maybe the orange for the words? > > > > On Dec 10, 2014, at 1:27 PM, Luk?? Fry? < lukas.fryc at gmail.com > wrote: > > Hello good people, > > Andres came with nice colour sets for a new Aerogear.org site. > > We would like you to consider which one fits the project best or simply which is a best option in your eyes! > > See the the poll here: > > http://goo.gl/forms/4YojF0DMbi > > > Cheers! > > ~ Lukas > _______________________________________________ > Aerogear-users mailing list > Aerogear-users at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 Dec 11 02:53:06 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 11 Dec 2014 08:53:06 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: <54886563.2050902@redhat.com> <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> Message-ID: Nice POC, Sebi! and great screencast! On Wed, Dec 10, 2014 at 8:55 PM, Corinne Krych wrote: > Nice POC indeed, it makes things more concrete. > > Looking at the the similar process for UGS and UPS and thinking we might > need similar mini/micro services, I have analytics in mind (e.g. leveraging RHQ metrics, as a possible option) > I think eventually we will benefit having a form of aggregator where you > say: create an app for UPS with plugin UGS, under the cover, 2 app ids are > created and unified with one appId + a map of corresponding app ids. > This overall aggregator would be an MBaaS, like FH or LiveOak. That's really not what we need to create here -Matthias > With the same idea some of the admin console for creating app could be > mutualised. > > This is more a ?for the future? improvement and does not interfere with > your POC. > > ++ > Corinne > > > On 10 Dec 2014, at 17:12, Sebastien Blanc wrote: > > > > > > > > On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante > wrote: > > Nice work Sebastien! > > If you I can help with app or console design, please let me know. > > Thanks ! A good strategy would probably to follow the Push Server and > LiveOak (Angular/patternfly) model. > > > > ----- Original Message ----- > > From: "Sebastien Blanc" > > To: "AeroGear Developer Mailing List" > > Sent: Wednesday, December 10, 2014 12:28:43 PM > > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > > > > > > > On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > > wrote: > > > > > > Really nice, looks great already, one question how do I use the data > > from the geo search to send push notifications? > > When the device registers to the geo server, it also provides an > "alias". The idea is that the developer has to use the same "alias" when > registering to the UPS, then it's up to the backend app to retrieve the > aliases for the geoserver and use these as criteria when sending a push > notif to UPS. > > It tried to described that here : > https://github.com/sebastienblanc/unified-geo-server#integration-with-push > > > > One idea for the alias, is to use the Keycloak (or whatever auth system) > username as alias to have it somehow "unified" > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.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/20141211/50f7075a/attachment.html From matzew at apache.org Thu Dec 11 02:53:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 11 Dec 2014 08:53:28 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: <1404943696.837339.1418241891351.JavaMail.zimbra@redhat.com> References: <54886563.2050902@redhat.com> <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> <1404943696.837339.1418241891351.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Dec 10, 2014 at 9:04 PM, Andres Galante wrote: > +1 > We are thinking of this kind of scenarios for the next step on the console > UI. Can you explain more? > The way we have the navigation now it is not flexible enough. Hopefully > I'll have updates on console UX to share with you soon :) > > > ----- Original Message ----- > From: "Corinne Krych" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 10, 2014 4:55:56 PM > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > Nice POC indeed, it makes things more concrete. > > Looking at the the similar process for UGS and UPS and thinking we might > need similar mini/micro services, I think eventually we will benefit having > a form of aggregator where you say: create an app for UPS with plugin UGS, > under the cover, 2 app ids are created and unified with one appId + a map > of corresponding app ids. > With the same idea some of the admin console for creating app could be > mutualised. > > This is more a ?for the future? improvement and does not interfere with > your POC. > > ++ > Corinne > > > On 10 Dec 2014, at 17:12, Sebastien Blanc wrote: > > > > > > > > On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante > wrote: > > Nice work Sebastien! > > If you I can help with app or console design, please let me know. > > Thanks ! A good strategy would probably to follow the Push Server and > LiveOak (Angular/patternfly) model. > > > > ----- Original Message ----- > > From: "Sebastien Blanc" > > To: "AeroGear Developer Mailing List" > > Sent: Wednesday, December 10, 2014 12:28:43 PM > > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > > > > > > > On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > > wrote: > > > > > > Really nice, looks great already, one question how do I use the data > > from the geo search to send push notifications? > > When the device registers to the geo server, it also provides an > "alias". The idea is that the developer has to use the same "alias" when > registering to the UPS, then it's up to the backend app to retrieve the > aliases for the geoserver and use these as criteria when sending a push > notif to UPS. > > It tried to described that here : > https://github.com/sebastienblanc/unified-geo-server#integration-with-push > > > > One idea for the alias, is to use the Keycloak (or whatever auth system) > username as alias to have it somehow "unified" > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.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/20141211/cafcea45/attachment-0001.html From corinnekrych at gmail.com Thu Dec 11 04:09:54 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 11 Dec 2014 10:09:54 +0100 Subject: [aerogear-dev] [Aerogear-users] [Poll] AeroGear.org Web Site Color Test In-Reply-To: <1243248424.836778.1418241264918.JavaMail.zimbra@redhat.com> References: <700DA584-7D60-49DE-8F13-E9BD5D522CB0@redhat.com> <1243248424.836778.1418241264918.JavaMail.zimbra@redhat.com> Message-ID: > On 10 Dec 2014, at 20:54, Andres Galante wrote: > > ...and the orange from the logo just doesn't have enough contrast, these are test with the exact same color of the logo, the logo from the inner "G" gear and an even lighter version of the same color: > > https://dl.dropboxusercontent.com/u/4371641/logo-color.png > https://dl.dropboxusercontent.com/u/4371641/logo-color2.png I have a 404 for logo-color2 :( > https://dl.dropboxusercontent.com/u/4371641/logo-color3.png > > > Is not even orange... is a kind of pinkish salmon color :p > > > > ----- Original Message ----- > From: "Lucas Holmquist" > To: aerogear-users at lists.jboss.org > Cc: "AeroGear Developer Mailing List" > Sent: Wednesday, December 10, 2014 4:20:15 PM > Subject: Re: [aerogear-dev] [Aerogear-users] [Poll] AeroGear.org Web Site Color Test > > i like the blue(color from the logo, voted for that one), but on the prototyped site, i think the yellow is to bright for the words, maybe the orange for the words? > > > > On Dec 10, 2014, at 1:27 PM, Luk?? Fry? < lukas.fryc at gmail.com > wrote: > > Hello good people, > > Andres came with nice colour sets for a new Aerogear.org site. > > We would like you to consider which one fits the project best or simply which is a best option in your eyes! > > See the the poll here: > > http://goo.gl/forms/4YojF0DMbi > > > Cheers! > > ~ Lukas > _______________________________________________ > Aerogear-users mailing list > Aerogear-users at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 danijel.kecman at gmail.com Thu Dec 11 07:11:00 2014 From: danijel.kecman at gmail.com (Danijel Kecman) Date: Thu, 11 Dec 2014 13:11:00 +0100 Subject: [aerogear-dev] AeroGear notifications Message-ID: Hi, I have a test env where my AeroGear is hosted at OpenShift. Suddenly I am not receiving any notifications, neither on my Android nor my iOS devices. I did not change anything in the code that could cause this. AeroGear on OpenShift responds properly. My .NET and Java code that does the calls to the AeroGear REST responds with success. Does anyone have similar experience? Thanks, Danijel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141211/2c997af3/attachment.html From agalante at redhat.com Thu Dec 11 07:36:22 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 11 Dec 2014 07:36:22 -0500 (EST) Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: <54886563.2050902@redhat.com> <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> <1404943696.837339.1418241891351.JavaMail.zimbra@redhat.com> Message-ID: <1330387029.903498.1418301382723.JavaMail.zimbra@redhat.com> Better show than tell, but I have nothing to show at the moment :( The problem with the current console is that the sidebar as a main navigation doesn't allow for sub navigation or expansions. We are researching with Matt and Gabriel applying paternally and how to adapt it to mobile products. There has been a lot of talk internally in the UX team but I haven't been able to start with it until yesterday. Since changing the console is not a short term goal, please give me a couple of days to work on it and I'll share as I have things to share. ----- Original Message ----- From: "Matthias Wessendorf" To: "AeroGear Developer Mailing List" Sent: Thursday, December 11, 2014 4:53:28 AM Subject: Re: [aerogear-dev] [POC] Unified Geo Server On Wed, Dec 10, 2014 at 9:04 PM, Andres Galante < agalante at redhat.com > wrote: +1 We are thinking of this kind of scenarios for the next step on the console UI. Can you explain more? The way we have the navigation now it is not flexible enough. Hopefully I'll have updates on console UX to share with you soon :) ----- Original Message ----- From: "Corinne Krych" < corinnekrych at gmail.com > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Wednesday, December 10, 2014 4:55:56 PM Subject: Re: [aerogear-dev] [POC] Unified Geo Server Nice POC indeed, it makes things more concrete. Looking at the the similar process for UGS and UPS and thinking we might need similar mini/micro services, I think eventually we will benefit having a form of aggregator where you say: create an app for UPS with plugin UGS, under the cover, 2 app ids are created and unified with one appId + a map of corresponding app ids. With the same idea some of the admin console for creating app could be mutualised. This is more a ?for the future? improvement and does not interfere with your POC. ++ Corinne > On 10 Dec 2014, at 17:12, Sebastien Blanc < scm.blanc at gmail.com > wrote: > > > > On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante < agalante at redhat.com > wrote: > Nice work Sebastien! > If you I can help with app or console design, please let me know. > Thanks ! A good strategy would probably to follow the Push Server and LiveOak (Angular/patternfly) model. > > ----- Original Message ----- > From: "Sebastien Blanc" < scm.blanc at gmail.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Sent: Wednesday, December 10, 2014 12:28:43 PM > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > > > On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > wrote: > > > Really nice, looks great already, one question how do I use the data > from the geo search to send push notifications? > When the device registers to the geo server, it also provides an "alias". The idea is that the developer has to use the same "alias" when registering to the UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use these as criteria when sending a push notif to UPS. > It tried to described that here : https://github.com/sebastienblanc/unified-geo-server#integration-with-push > > One idea for the alias, is to use the Keycloak (or whatever auth system) username as alias to have it somehow "unified" > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 From agalante at redhat.com Thu Dec 11 08:02:28 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 11 Dec 2014 08:02:28 -0500 (EST) Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <601330843.904188.1418302277352.JavaMail.zimbra@redhat.com> Message-ID: <266736271.905177.1418302948268.JavaMail.zimbra@redhat.com> Hi! Since the main discussion on the website now is weather what color to use I think we can move to implementation. Styling and color changes are not a blocker. But before that, I want to make sure we have a solid structure. These are three concerns I've heard that we can discuss: - Roadmaps should be feature specific instead of platform specific http://andresgalante.com/aerogearwebsite/roadmap.html - We should move Demos and Guides under "Get Started" - I've changed main title to make sure the right audience (enterprise mobile developers) know this is a place for them. Now it reads: "Bringing mobile and enterprise together." is it ok? What do you think? From agalante at redhat.com Thu Dec 11 08:06:30 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 11 Dec 2014 08:06:30 -0500 (EST) Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <266736271.905177.1418302948268.JavaMail.zimbra@redhat.com> References: <266736271.905177.1418302948268.JavaMail.zimbra@redhat.com> Message-ID: <741977381.905408.1418303190781.JavaMail.zimbra@redhat.com> Sorry there is one more: - Sidebar and content area: Should we have the sidebar on the left like ionic [1] or on the right like bootstrap [2] ? [1]http://ionicframework.com/docs/components/#header [2]http://getbootstrap.com/css/ I can send images of how our website look with both versions if needed. ----- Original Message ----- From: "Andres Galante" To: "AeroGear Developer Mailing List" Sent: Thursday, December 11, 2014 10:02:28 AM Subject: [aerogear-dev] Website structural changes and implementation Hi! Since the main discussion on the website now is weather what color to use I think we can move to implementation. Styling and color changes are not a blocker. But before that, I want to make sure we have a solid structure. These are three concerns I've heard that we can discuss: - Roadmaps should be feature specific instead of platform specific http://andresgalante.com/aerogearwebsite/roadmap.html - We should move Demos and Guides under "Get Started" - I've changed main title to make sure the right audience (enterprise mobile developers) know this is a place for them. Now it reads: "Bringing mobile and enterprise together." is it ok? What do you think? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Dec 11 09:13:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 11 Dec 2014 15:13:48 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: <1330387029.903498.1418301382723.JavaMail.zimbra@redhat.com> References: <54886563.2050902@redhat.com> <1621879902.820002.1418226401342.JavaMail.zimbra@redhat.com> <1404943696.837339.1418241891351.JavaMail.zimbra@redhat.com> <1330387029.903498.1418301382723.JavaMail.zimbra@redhat.com> Message-ID: On Thu, Dec 11, 2014 at 1:36 PM, Andres Galante wrote: > Better show than tell, but I have nothing to show at the moment :( > > The problem with the current console is that the sidebar as a main > navigation doesn't allow for sub navigation or expansions. We are > researching with Matt and Gabriel applying paternally and how to adapt it > to mobile products. ah, you mean generic - not specific to this POC. For this POC, let's just focus on the RESTful endpoints, not the UI at the moment - it's a proof of concepts, not more -M > There has been a lot of talk internally in the UX team but I haven't been > able to start with it until yesterday. > > Since changing the console is not a short term goal, please give me a > couple of days to work on it and I'll share as I have things to share. > > ----- Original Message ----- > From: "Matthias Wessendorf" > To: "AeroGear Developer Mailing List" > Sent: Thursday, December 11, 2014 4:53:28 AM > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > > > On Wed, Dec 10, 2014 at 9:04 PM, Andres Galante < agalante at redhat.com > > wrote: > > > +1 > We are thinking of this kind of scenarios for the next step on the console > UI. > > Can you explain more? > > > > The way we have the navigation now it is not flexible enough. Hopefully > I'll have updates on console UX to share with you soon :) > > > ----- Original Message ----- > From: "Corinne Krych" < corinnekrych at gmail.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Sent: Wednesday, December 10, 2014 4:55:56 PM > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > Nice POC indeed, it makes things more concrete. > > Looking at the the similar process for UGS and UPS and thinking we might > need similar mini/micro services, I think eventually we will benefit having > a form of aggregator where you say: create an app for UPS with plugin UGS, > under the cover, 2 app ids are created and unified with one appId + a map > of corresponding app ids. > With the same idea some of the admin console for creating app could be > mutualised. > > This is more a ?for the future? improvement and does not interfere with > your POC. > > ++ > Corinne > > > On 10 Dec 2014, at 17:12, Sebastien Blanc < scm.blanc at gmail.com > wrote: > > > > > > > > On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante < agalante at redhat.com > > wrote: > > Nice work Sebastien! > > If you I can help with app or console design, please let me know. > > Thanks ! A good strategy would probably to follow the Push Server and > LiveOak (Angular/patternfly) model. > > > > ----- Original Message ----- > > From: "Sebastien Blanc" < scm.blanc at gmail.com > > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > > Sent: Wednesday, December 10, 2014 12:28:43 PM > > Subject: Re: [aerogear-dev] [POC] Unified Geo Server > > > > > > > > On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit at redhat.com > > wrote: > > > > > > Really nice, looks great already, one question how do I use the data > > from the geo search to send push notifications? > > When the device registers to the geo server, it also provides an > "alias". The idea is that the developer has to use the same "alias" when > registering to the UPS, then it's up to the backend app to retrieve the > aliases for the geoserver and use these as criteria when sending a push > notif to UPS. > > It tried to described that here : > https://github.com/sebastienblanc/unified-geo-server#integration-with-push > > > > One idea for the alias, is to use the Keycloak (or whatever auth system) > username as alias to have it somehow "unified" > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.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/20141211/9afd1c92/attachment-0001.html From kpiwko at redhat.com Thu Dec 11 09:46:30 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 11 Dec 2014 14:46:30 +0000 Subject: [aerogear-dev] Travis-ci and CloudBees problems on Android land In-Reply-To: References: Message-ID: <1418309190.4779.33.camel@kpiwko-x220> Hi Passos, have you enabled XVnc / Framebuffer on Jenkins? It looks that it might be related to the log output. If you have issues with Android SDK version and/or applying any configuration to existing installation, I'd suggest to use Arquillian Gradle Spacelift, which is able to bring Android SDK runtime there for you very cheaply. Stefan has automated testsuite for our Android ftesting tool that way, so if you have a Linux machine (adding support for Mac OS X should be pretty easy), you just need to clone and run Gradle. https://github.com/arquillian/arquillian-droidium/tree/master/tests Maybe it could be reused for Android integration tests? Also I'd suggest not to use ARMv7 ABI but x86 based one. For most CI setups ARMv7 means a VM in VM and that is terribly slow unless you have nested VM support in both HW and SW - which you most likely don't have ;-) Karel On Mon, 2014-12-08 at 13:59 -0200, Daniel Passos wrote: > Hi All, > > > The Android team has been working on resolving a travis build issue > last week (and part of weekend) with travis-ci[1][2]. I has been > testing with proting the build to cloudbees[3][4]. > > > travis-ci: > > > In Travis the VM is running out of memory and getting killed. We fixed > this by starting the emulator after compiling and I was able to make > it pass 2 times[5][6], but when a PR[7] for AG was sent, we were back > to the old problem[8] (travis-ci killed our build, because it's using > a lot of memory) > > > CloudBees: > > > We are having trouble running the emulator[9] on CloudBees ([android] > Emulator did not appear to start; giving up). We found a fix[10] but > are not sure if we can apply it on CloudBees > > > [1] > https://travis-ci.org/danielpassos/aerogear-android-security/builds > [2] https://travis-ci.org/secondsun/aerogear-android-security/builds > [3] https://aerogear.ci.cloudbees.com/job/aerogear-android-security > [4] https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe > [5] > https://travis-ci.org/danielpassos/aerogear-android-security/builds/43219446 > [6] > https://travis-ci.org/danielpassos/aerogear-android-security/builds/43256877 > [7] https://github.com/aerogear/aerogear-android-security/pull/17 > [8] > https://travis-ci.org/aerogear/aerogear-android-security/builds/43295194 > [9] > https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe/6/jdk=openjdk8/console > [10]: > http://stackoverflow.com/questions/19349222/jenkins-android-emulator-emulator-did-not-appear-to-start-giving-up > > > -- Passos > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lukas.fryc at gmail.com Thu Dec 11 10:24:23 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 11 Dec 2014 16:24:23 +0100 Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <741977381.905408.1418303190781.JavaMail.zimbra@redhat.com> References: <266736271.905177.1418302948268.JavaMail.zimbra@redhat.com> <741977381.905408.1418303190781.JavaMail.zimbra@redhat.com> Message-ID: Hey Andres, all suggested changes sounds good to me personally +1 for sidebar on the left, seems like more straight-forward way to communicate the page structure then the right version On Thu, Dec 11, 2014 at 2:06 PM, Andres Galante wrote: > Sorry there is one more: > > - Sidebar and content area: Should we have the sidebar on the left like > ionic [1] or on the right like bootstrap [2] ? > > [1]http://ionicframework.com/docs/components/#header > [2]http://getbootstrap.com/css/ > > I can send images of how our website look with both versions if needed. > > > ----- Original Message ----- > From: "Andres Galante" > To: "AeroGear Developer Mailing List" > Sent: Thursday, December 11, 2014 10:02:28 AM > Subject: [aerogear-dev] Website structural changes and implementation > > Hi! > > Since the main discussion on the website now is weather what color to use > I think we can move to implementation. Styling and color changes are not a > blocker. > > But before that, I want to make sure we have a solid structure. These are > three concerns I've heard that we can discuss: > > - Roadmaps should be feature specific instead of platform specific > http://andresgalante.com/aerogearwebsite/roadmap.html > > - We should move Demos and Guides under "Get Started" > > - I've changed main title to make sure the right audience (enterprise > mobile developers) know this is a place for them. > Now it reads: "Bringing mobile and enterprise together." is it ok? > > What do you think? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141211/d2b2e71f/attachment.html From supittma at redhat.com Thu Dec 11 10:04:50 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 11 Dec 2014 10:04:50 -0500 Subject: [aerogear-dev] Travis-ci and CloudBees problems on Android land In-Reply-To: <1418309190.4779.33.camel@kpiwko-x220> References: <1418309190.4779.33.camel@kpiwko-x220> Message-ID: <5489B292.2030401@redhat.com> On 12/11/2014 09:46 AM, Karel Piwko wrote: > Hi Passos, > > have you enabled XVnc / Framebuffer on Jenkins? It looks that it might > be related to the log output. > > If you have issues with Android SDK version and/or applying any > configuration to existing installation, I'd suggest to use Arquillian > Gradle Spacelift, which is able to bring Android SDK runtime there for > you very cheaply. Stefan has automated testsuite for our Android > ftesting tool that way, so if you have a Linux machine (adding support > for Mac OS X should be pretty easy), you just need to clone and run > Gradle. And port the project to Gradle from Maven. > > https://github.com/arquillian/arquillian-droidium/tree/master/tests > > Maybe it could be reused for Android integration tests? > > Also I'd suggest not to use ARMv7 ABI but x86 based one. For most CI > setups ARMv7 means a VM in VM and that is terribly slow unless you have > nested VM support in both HW and SW - which you most likely don't > have ;-) x86 has the same problem unless the environment has KVM installed. I know Travis CI does not and I know that in all of CloudBees' docs it refers to the arm emulator instead of using x86. > > Karel We've also got the build running in Travis again by being much smarter about when we start and stop the emulator and project compiling. > > On Mon, 2014-12-08 at 13:59 -0200, Daniel Passos wrote: >> Hi All, >> >> >> The Android team has been working on resolving a travis build issue >> last week (and part of weekend) with travis-ci[1][2]. I has been >> testing with proting the build to cloudbees[3][4]. >> >> >> travis-ci: >> >> >> In Travis the VM is running out of memory and getting killed. We fixed >> this by starting the emulator after compiling and I was able to make >> it pass 2 times[5][6], but when a PR[7] for AG was sent, we were back >> to the old problem[8] (travis-ci killed our build, because it's using >> a lot of memory) >> >> >> CloudBees: >> >> >> We are having trouble running the emulator[9] on CloudBees ([android] >> Emulator did not appear to start; giving up). We found a fix[10] but >> are not sure if we can apply it on CloudBees >> >> >> [1] >> https://travis-ci.org/danielpassos/aerogear-android-security/builds >> [2] https://travis-ci.org/secondsun/aerogear-android-security/builds >> [3] https://aerogear.ci.cloudbees.com/job/aerogear-android-security >> [4] https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe >> [5] >> https://travis-ci.org/danielpassos/aerogear-android-security/builds/43219446 >> [6] >> https://travis-ci.org/danielpassos/aerogear-android-security/builds/43256877 >> [7] https://github.com/aerogear/aerogear-android-security/pull/17 >> [8] >> https://travis-ci.org/aerogear/aerogear-android-security/builds/43295194 >> [9] >> https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe/6/jdk=openjdk8/console >> [10]: >> http://stackoverflow.com/questions/19349222/jenkins-android-emulator-emulator-did-not-appear-to-start-giving-up >> >> >> -- 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 -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From lholmqui at redhat.com Thu Dec 11 11:38:45 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 11 Dec 2014 11:38:45 -0500 Subject: [aerogear-dev] Diff Sync POC, Again Message-ID: <11E0F455-B463-4927-AA0D-095949A02335@redhat.com> I decided to implement the current Diff Sync POC that we have, https://github.com/aerogear/aerogear-sync-server/tree/master/js-client , using Ember and the ember-cli here it is: https://github.com/lholmquist/diff-sync-demo don?t forget that you will also need to run the diff-sync server for it to work, https://github.com/aerogear/aerogear-sync-server it?s pretty cool how much less code there is -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141211/fd2da1d1/attachment.html From kpiwko at redhat.com Thu Dec 11 13:19:03 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 11 Dec 2014 18:19:03 +0000 Subject: [aerogear-dev] Travis-ci and CloudBees problems on Android land In-Reply-To: <5489B292.2030401@redhat.com> References: <1418309190.4779.33.camel@kpiwko-x220> <5489B292.2030401@redhat.com> Message-ID: <1418321943.4779.38.camel@kpiwko-x220> On Thu, 2014-12-11 at 10:04 -0500, Summers Pittman wrote: > On 12/11/2014 09:46 AM, Karel Piwko wrote: > > Hi Passos, > > > > have you enabled XVnc / Framebuffer on Jenkins? It looks that it might > > be related to the log output. > > > > If you have issues with Android SDK version and/or applying any > > configuration to existing installation, I'd suggest to use Arquillian > > Gradle Spacelift, which is able to bring Android SDK runtime there for > > you very cheaply. Stefan has automated testsuite for our Android > > ftesting tool that way, so if you have a Linux machine (adding support > > for Mac OS X should be pretty easy), you just need to clone and run > > Gradle. > And port the project to Gradle from Maven. Well, not really, Gradle actually calls Maven, so the project itself stays unchanged. > > > > https://github.com/arquillian/arquillian-droidium/tree/master/tests > > > > Maybe it could be reused for Android integration tests? > > > > Also I'd suggest not to use ARMv7 ABI but x86 based one. For most CI > > setups ARMv7 means a VM in VM and that is terribly slow unless you have > > nested VM support in both HW and SW - which you most likely don't > > have ;-) > x86 has the same problem unless the environment has KVM installed. I > know Travis CI does not and I know that in all of CloudBees' docs it > refers to the arm emulator instead of using x86. Thanks, that's a very valuable piece of information. > > > > Karel > We've also got the build running in Travis again by being much smarter > about when we start and stop the emulator and project compiling. Sweet! > > > > On Mon, 2014-12-08 at 13:59 -0200, Daniel Passos wrote: > >> Hi All, > >> > >> > >> The Android team has been working on resolving a travis build issue > >> last week (and part of weekend) with travis-ci[1][2]. I has been > >> testing with proting the build to cloudbees[3][4]. > >> > >> > >> travis-ci: > >> > >> > >> In Travis the VM is running out of memory and getting killed. We fixed > >> this by starting the emulator after compiling and I was able to make > >> it pass 2 times[5][6], but when a PR[7] for AG was sent, we were back > >> to the old problem[8] (travis-ci killed our build, because it's using > >> a lot of memory) > >> > >> > >> CloudBees: > >> > >> > >> We are having trouble running the emulator[9] on CloudBees ([android] > >> Emulator did not appear to start; giving up). We found a fix[10] but > >> are not sure if we can apply it on CloudBees > >> > >> > >> [1] > >> https://travis-ci.org/danielpassos/aerogear-android-security/builds > >> [2] https://travis-ci.org/secondsun/aerogear-android-security/builds > >> [3] https://aerogear.ci.cloudbees.com/job/aerogear-android-security > >> [4] https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe > >> [5] > >> https://travis-ci.org/danielpassos/aerogear-android-security/builds/43219446 > >> [6] > >> https://travis-ci.org/danielpassos/aerogear-android-security/builds/43256877 > >> [7] https://github.com/aerogear/aerogear-android-security/pull/17 > >> [8] > >> https://travis-ci.org/aerogear/aerogear-android-security/builds/43295194 > >> [9] > >> https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe/6/jdk=openjdk8/console > >> [10]: > >> http://stackoverflow.com/questions/19349222/jenkins-android-emulator-emulator-did-not-appear-to-start-giving-up > >> > >> > >> -- 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 > > From agalante at redhat.com Thu Dec 11 14:27:18 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 11 Dec 2014 14:27:18 -0500 (EST) Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: References: <266736271.905177.1418302948268.JavaMail.zimbra@redhat.com> <741977381.905408.1418303190781.JavaMail.zimbra@redhat.com> Message-ID: <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> Hi! I've made all the changes and other small things, and it looks like this: http://andresgalante.com/aerogearwebsite/ Should I start integration with Jekyll? ----- Original Message ----- From: "Luk?? Fry?" To: "AeroGear Developer Mailing List" Sent: Thursday, December 11, 2014 12:24:23 PM Subject: Re: [aerogear-dev] Website structural changes and implementation Hey Andres, all suggested changes sounds good to me personally +1 for sidebar on the left, seems like more straight-forward way to communicate the page structure then the right version On Thu, Dec 11, 2014 at 2:06 PM, Andres Galante < agalante at redhat.com > wrote: Sorry there is one more: - Sidebar and content area: Should we have the sidebar on the left like ionic [1] or on the right like bootstrap [2] ? [1] http://ionicframework.com/docs/components/#header [2] http://getbootstrap.com/css/ I can send images of how our website look with both versions if needed. ----- Original Message ----- From: "Andres Galante" < agalante at redhat.com > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Thursday, December 11, 2014 10:02:28 AM Subject: [aerogear-dev] Website structural changes and implementation Hi! Since the main discussion on the website now is weather what color to use I think we can move to implementation. Styling and color changes are not a blocker. But before that, I want to make sure we have a solid structure. These are three concerns I've heard that we can discuss: - Roadmaps should be feature specific instead of platform specific http://andresgalante.com/aerogearwebsite/roadmap.html - We should move Demos and Guides under "Get Started" - I've changed main title to make sure the right audience (enterprise mobile developers) know this is a place for them. Now it reads: "Bringing mobile and enterprise together." is it ok? What do you think? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 bruno at abstractj.org Fri Dec 12 02:01:15 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 11 Dec 2014 23:01:15 -0800 (PST) Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> References: <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> Message-ID: <1418367675134.24f18f08@Nodemailer> +1 go ahead? ? abstractj PGP: 0x84DC9914 On Thu, Dec 11, 2014 at 5:27 PM, Andres Galante wrote: > Hi! > I've made all the changes and other small things, and it looks like this: > http://andresgalante.com/aerogearwebsite/ > Should I start integration with Jekyll? > ----- Original Message ----- > From: "Luk?? Fry?" > To: "AeroGear Developer Mailing List" > Sent: Thursday, December 11, 2014 12:24:23 PM > Subject: Re: [aerogear-dev] Website structural changes and implementation > Hey Andres, > all suggested changes sounds good to me personally > +1 for sidebar on the left, seems like more straight-forward way to communicate the page structure then the right version > On Thu, Dec 11, 2014 at 2:06 PM, Andres Galante < agalante at redhat.com > wrote: > Sorry there is one more: > - Sidebar and content area: Should we have the sidebar on the left like ionic [1] or on the right like bootstrap [2] ? > [1] http://ionicframework.com/docs/components/#header > [2] http://getbootstrap.com/css/ > I can send images of how our website look with both versions if needed. > ----- Original Message ----- > From: "Andres Galante" < agalante at redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Sent: Thursday, December 11, 2014 10:02:28 AM > Subject: [aerogear-dev] Website structural changes and implementation > Hi! > Since the main discussion on the website now is weather what color to use I think we can move to implementation. Styling and color changes are not a blocker. > But before that, I want to make sure we have a solid structure. These are three concerns I've heard that we can discuss: > - Roadmaps should be feature specific instead of platform specific > http://andresgalante.com/aerogearwebsite/roadmap.html > - We should move Demos and Guides under "Get Started" > - I've changed main title to make sure the right audience (enterprise mobile developers) know this is a place for them. > Now it reads: "Bringing mobile and enterprise together." is it ok? > What do you think? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141211/cea73fff/attachment.html From daniel.bevenius at gmail.com Fri Dec 12 02:13:23 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 12 Dec 2014 08:13:23 +0100 Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <1418367675134.24f18f08@Nodemailer> References: <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> <1418367675134.24f18f08@Nodemailer> Message-ID: +1 fredag 12 december 2014 skrev Bruno Oliveira : > +1 go ahead > > ? > abstractj > PGP: 0x84DC9914 > > > On Thu, Dec 11, 2014 at 5:27 PM, Andres Galante > wrote: > >> Hi! >> >> I've made all the changes and other small things, and it looks like this: >> >> http://andresgalante.com/aerogearwebsite/ >> >> Should I start integration with Jekyll? >> >> >> >> ----- Original Message ----- >> From: "Luk?? Fry?" > > >> To: "AeroGear Developer Mailing List" > > >> Sent: Thursday, December 11, 2014 12:24:23 PM >> Subject: Re: [aerogear-dev] Website structural changes and implementation >> >> Hey Andres, >> >> all suggested changes sounds good to me personally >> >> +1 for sidebar on the left, seems like more straight-forward way to >> communicate the page structure then the right version >> >> On Thu, Dec 11, 2014 at 2:06 PM, Andres Galante < agalante at redhat.com >> > wrote: >> >> >> Sorry there is one more: >> >> - Sidebar and content area: Should we have the sidebar on the left like >> ionic [1] or on the right like bootstrap [2] ? >> >> [1] http://ionicframework.com/docs/components/#header >> [2] http://getbootstrap.com/css/ >> >> I can send images of how our website look with both versions if needed. >> >> >> ----- Original Message ----- >> From: "Andres Galante" < agalante at redhat.com >> > >> To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org >> > >> Sent: Thursday, December 11, 2014 10:02:28 AM >> Subject: [aerogear-dev] Website structural changes and implementation >> >> Hi! >> >> Since the main discussion on the website now is weather what color to use >> I think we can move to implementation. Styling and color changes are not a >> blocker. >> >> But before that, I want to make sure we have a solid structure. These are >> three concerns I've heard that we can discuss: >> >> - Roadmaps should be feature specific instead of platform specific >> http://andresgalante.com/aerogearwebsite/roadmap.html >> >> - We should move Demos and Guides under "Get Started" >> >> - I've changed main title to make sure the right audience (enterprise >> mobile developers) know this is a place for them. >> Now it reads: "Bringing mobile and enterprise together." is it ok? >> >> What do you think? >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.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/20141212/9e217b38/attachment.html From matzew at apache.org Fri Dec 12 03:15:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 12 Dec 2014 09:15:05 +0100 Subject: [aerogear-dev] AeroGear notifications In-Reply-To: References: Message-ID: Hey Danijel, did you try sending messages using the UI, on the Unified Push Server ? On Thu, Dec 11, 2014 at 1:11 PM, Danijel Kecman wrote: > Hi, > > I have a test env where my AeroGear is hosted at OpenShift. Suddenly I am > not receiving any notifications, neither on my Android nor my iOS devices. > I did not change anything in the code that could cause this. AeroGear on > OpenShift responds properly. My .NET and Java code that does the calls to > the AeroGear REST responds with success. Does anyone have similar > experience? > > Thanks, > Danijel > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141212/f138aeb1/attachment.html From matzew at apache.org Fri Dec 12 08:57:04 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 12 Dec 2014 14:57:04 +0100 Subject: [aerogear-dev] UnifiedPush Server: updates on roadmap and future versions Message-ID: Hi team, due to an issue with migration of Keycloak and our own models, the 1.0.3 release (see [1]) is delayed and will not happen in 2014. It's planed to have the release out in mid (late?) January 2015. Note: the 1.0.3 release will be (most-likely) the last release on the 1.0.x series :-) In 2015 the focus, for the Unified Push Server, will be on the 1.1.0 release. A first alpha, supporting Windows Phone, has been released already (see [2]). In addition I have also updated our roadmap, see [3]. Any thoughts or feedback is more than welcome! Greetings, Matthias [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12325082 [2] https://aerogear.org/news/2014/12/03/aerogear-unified-push-alpha1-is-out/index.html [3] https://github.com/aerogear/aerogear.org/pull/441 -- 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/20141212/9dac45b8/attachment-0001.html From matzew at apache.org Fri Dec 12 14:56:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 12 Dec 2014 20:56:21 +0100 Subject: [aerogear-dev] Diff Sync POC, Again In-Reply-To: <11E0F455-B463-4927-AA0D-095949A02335@redhat.com> References: <11E0F455-B463-4927-AA0D-095949A02335@redhat.com> Message-ID: On Thursday, December 11, 2014, Lucas Holmquist wrote: > I decided to implement the current Diff Sync POC that we have, > https://github.com/aerogear/aerogear-sync-server/tree/master/js-client , > using Ember and the ember-cli > > here it is: > https://github.com/lholmquist/diff-sync-demo > > > don?t forget that you will also need to run the diff-sync server for it to > work, https://github.com/aerogear/aerogear-sync-server > > > > it?s pretty cool how much less code there is > less than w/ vanilla js/node? -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141212/77e316c4/attachment.html From lholmqui at redhat.com Fri Dec 12 14:58:32 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 12 Dec 2014 14:58:32 -0500 Subject: [aerogear-dev] Diff Sync POC, Again In-Reply-To: References: <11E0F455-B463-4927-AA0D-095949A02335@redhat.com> Message-ID: <70218CA3-B942-42E8-8B87-51BF1F16E472@redhat.com> > On Dec 12, 2014, at 2:56 PM, Matthias Wessendorf wrote: > > > > On Thursday, December 11, 2014, Lucas Holmquist > wrote: > I decided to implement the current Diff Sync POC that we have, https://github.com/aerogear/aerogear-sync-server/tree/master/js-client , using Ember and the ember-cli > > here it is: > https://github.com/lholmquist/diff-sync-demo > > > don?t forget that you will also need to run the diff-sync server for it to work, https://github.com/aerogear/aerogear-sync-server > > > > it?s pretty cool how much less code there is > > less than w/ vanilla js/node? > Basically, all the ?update the UI? code, ember takes care of > > -- > 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/20141212/f25bf659/attachment.html From matzew at apache.org Fri Dec 12 15:09:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 12 Dec 2014 21:09:49 +0100 Subject: [aerogear-dev] Diff Sync POC, Again In-Reply-To: <70218CA3-B942-42E8-8B87-51BF1F16E472@redhat.com> References: <11E0F455-B463-4927-AA0D-095949A02335@redhat.com> <70218CA3-B942-42E8-8B87-51BF1F16E472@redhat.com> Message-ID: ah, ok so unrealted to the actual js engine On Friday, December 12, 2014, Lucas Holmquist wrote: > > On Dec 12, 2014, at 2:56 PM, Matthias Wessendorf > wrote: > > > > On Thursday, December 11, 2014, Lucas Holmquist > wrote: > >> I decided to implement the current Diff Sync POC that we have, >> https://github.com/aerogear/aerogear-sync-server/tree/master/js-client >> , using Ember and the ember-cli >> >> here it is: >> https://github.com/lholmquist/diff-sync-demo >> >> >> don?t forget that you will also need to run the diff-sync server for it >> to work, https://github.com/aerogear/aerogear-sync-server >> >> >> >> it?s pretty cool how much less code there is >> > > less than w/ vanilla js/node? > > Basically, all the ?update the UI? code, ember takes care of > > > > -- > 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/20141212/a1278ef0/attachment.html From agalante at redhat.com Fri Dec 12 16:12:06 2014 From: agalante at redhat.com (Andres Galante) Date: Fri, 12 Dec 2014 16:12:06 -0500 (EST) Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: References: <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> <1418367675134.24f18f08@Nodemailer> Message-ID: <547301999.1047005.1418418726344.JavaMail.zimbra@redhat.com> I started implementation today. You can follow the progress here: https://github.com/andresgalante/aerogear.org/tree/new-design ----- Original Message ----- From: "Daniel Bevenius" To: "AeroGear Developer Mailing List" Sent: Friday, December 12, 2014 4:13:23 AM Subject: Re: [aerogear-dev] Website structural changes and implementation +1 fredag 12 december 2014 skrev Bruno Oliveira < bruno at abstractj.org >: +1 go ahead ? abstractj PGP: 0x84DC9914 On Thu, Dec 11, 2014 at 5:27 PM, Andres Galante < agalante at redhat.com > wrote: Hi! I've made all the changes and other small things, and it looks like this: http://andresgalante.com/aerogearwebsite/ Should I start integration with Jekyll? ----- Original Message ----- From: "Luk?? Fry?" < lukas.fryc at gmail.com > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Thursday, December 11, 2014 12:24:23 PM Subject: Re: [aerogear-dev] Website structural changes and implementation Hey Andres, all suggested changes sounds good to me personally +1 for sidebar on the left, seems like more straight-forward way to communicate the page structure then the right version On Thu, Dec 11, 2014 at 2:06 PM, Andres Galante < agalante at redhat.com > wrote: Sorry there is one more: - Sidebar and content area: Should we have the sidebar on the left like ionic [1] or on the right like bootstrap [2] ? [1] http://ionicframework.com/docs/components/#header [2] http://getbootstrap.com/css/ I can send images of how our website look with both versions if needed. ----- Original Message ----- From: "Andres Galante" < agalante at redhat.com > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Thursday, December 11, 2014 10:02:28 AM Subject: [aerogear-dev] Website structural changes and implementation Hi! Since the main discussion on the website now is weather what color to use I think we can move to implementation. Styling and color changes are not a blocker. But before that, I want to make sure we have a solid structure. These are three concerns I've heard that we can discuss: - Roadmaps should be feature specific instead of platform specific http://andresgalante.com/aerogearwebsite/roadmap.html - We should move Demos and Guides under "Get Started" - I've changed main title to make sure the right audience (enterprise mobile developers) know this is a place for them. Now it reads: "Bringing mobile and enterprise together." is it ok? What do you think? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 From bruno at abstractj.org Fri Dec 12 16:20:37 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 12 Dec 2014 19:20:37 -0200 Subject: [aerogear-dev] UnifiedPush Server: updates on roadmap and future versions In-Reply-To: References: Message-ID: <20141212212037.GB21647@abstractj.org> Hi Matthias, I guess the issue is related with AGPUSH-1134, right? Could you please provide the exact steps to reproduce the issue? Here I did: 1. git clone git at github.com:aerogear/aerogear-parent.git && cd aerogear-parent && mvn clean install 2. changed UPS pom.xml: aerogear-parent 0.2.11-SNAPSHOT 3. On master branch: cd aerogear-unifiedpush-server && cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments 4. cp servers/auth-server/target/auth-server.war $JBOSS_HOME/standalone/deployments 5. cp servers/ups-wildfly/target/ag-push.war $JBOSS_HOME/standalone/deployments I'm running on WildFly 8.1 and everything is working like expected. A more detailed information would help to reproduce the issue like which database and the steps to reproduce. Thanks in advance. On 2014-12-12, Matthias Wessendorf wrote: > Hi team, > > due to an issue with migration of Keycloak and our own models, the 1.0.3 > release (see [1]) is delayed and will not happen in 2014. It's planed to > have the release out in mid (late?) January 2015. > > Note: the 1.0.3 release will be (most-likely) the last release on the 1.0.x > series :-) > > In 2015 the focus, for the Unified Push Server, will be on the 1.1.0 > release. A first alpha, supporting Windows Phone, has been released already > (see [2]). > > In addition I have also updated our roadmap, see [3]. > > Any thoughts or feedback is more than welcome! > > Greetings, > Matthias > > [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12325082 > [2] > https://aerogear.org/news/2014/12/03/aerogear-unified-push-alpha1-is-out/index.html > [3] https://github.com/aerogear/aerogear.org/pull/441 > > > -- > 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 cvasilak at gmail.com Fri Dec 12 17:45:32 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Sat, 13 Dec 2014 00:45:32 +0200 Subject: [aerogear-dev] Diff Sync POC, Again In-Reply-To: <11E0F455-B463-4927-AA0D-095949A02335@redhat.com> References: <11E0F455-B463-4927-AA0D-095949A02335@redhat.com> Message-ID: Hi Lucas > On Dec 11, 2014, at 6:38 PM, Lucas Holmquist wrote: > > I decided to implement the current Diff Sync POC that we have, nice work keep up exploring the territory > https://github.com/aerogear/aerogear-sync-server/tree/master/js-client , using Ember and the ember-cli > > here it is: > https://github.com/lholmquist/diff-sync-demo > let me give a shot, looks interesting > > don?t forget that you will also need to run the diff-sync server for it to work, https://github.com/aerogear/aerogear-sync-server > > > > it?s pretty cool how much less code there is nice to hear! > _______________________________________________ > 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/20141213/cc17a3d1/attachment-0001.html From danijel.kecman at gmail.com Sat Dec 13 02:04:00 2014 From: danijel.kecman at gmail.com (Danijel Kecman) Date: Sat, 13 Dec 2014 08:04:00 +0100 Subject: [aerogear-dev] AeroGear notifications In-Reply-To: References: Message-ID: Hi Matthias, I have upgraded the aerogear instance and the problem went away. I recall now that I had upgraded the SDKs. It might be it, or, I suspect, it might be just a bad connection on the OpenShift side, me bing in the EU ant the server on the US west. Thank you, Danijel On Fri, Dec 12, 2014 at 9:15 AM, Matthias Wessendorf wrote: > > Hey Danijel, > > did you try sending messages using the UI, on the Unified Push Server ? > > On Thu, Dec 11, 2014 at 1:11 PM, Danijel Kecman > wrote: > >> Hi, >> >> I have a test env where my AeroGear is hosted at OpenShift. Suddenly I am >> not receiving any notifications, neither on my Android nor my iOS devices. >> I did not change anything in the code that could cause this. AeroGear on >> OpenShift responds properly. My .NET and Java code that does the calls to >> the AeroGear REST responds with success. Does anyone have similar >> experience? >> >> Thanks, >> Danijel >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141213/95f7ca26/attachment.html From matzew at apache.org Sat Dec 13 02:06:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 13 Dec 2014 08:06:29 +0100 Subject: [aerogear-dev] UnifiedPush Server: updates on roadmap and future versions In-Reply-To: <20141212212037.GB21647@abstractj.org> References: <20141212212037.GB21647@abstractj.org> Message-ID: Hello Bruno! On Fri, Dec 12, 2014 at 10:20 PM, Bruno Oliveira wrote: > > Hi Matthias, I guess the issue is related with AGPUSH-1134, right? > No, the delay of 1.0.3 is related to AGPUSH-1135 and AGPUSH-1136 (related to KC 1.0.x). AGPUSH-1134 is related to using the KC 1.1.beta2. I got the stack-trace when deploying the server to WF 8.2. I will take a look at it again next week, and provide detailed steps on the JIRA. -Matthias > > Could you please provide the exact steps to reproduce the issue? Here I > did: > > 1. git clone git at github.com:aerogear/aerogear-parent.git && cd > aerogear-parent && mvn clean install > 2. changed UPS pom.xml: > > aerogear-parent > 0.2.11-SNAPSHOT > > 3. On master branch: cd aerogear-unifiedpush-server && cp > databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments > 4. cp servers/auth-server/target/auth-server.war > $JBOSS_HOME/standalone/deployments > 5. cp servers/ups-wildfly/target/ag-push.war > $JBOSS_HOME/standalone/deployments > > I'm running on WildFly 8.1 and everything is working like expected. A > more detailed information would help to reproduce the issue like which > database and the steps to reproduce. > > Thanks in advance. > > > On 2014-12-12, Matthias Wessendorf wrote: > > Hi team, > > > > due to an issue with migration of Keycloak and our own models, the 1.0.3 > > release (see [1]) is delayed and will not happen in 2014. It's planed to > > have the release out in mid (late?) January 2015. > > > > Note: the 1.0.3 release will be (most-likely) the last release on the > 1.0.x > > series :-) > > > > In 2015 the focus, for the Unified Push Server, will be on the 1.1.0 > > release. A first alpha, supporting Windows Phone, has been released > already > > (see [2]). > > > > In addition I have also updated our roadmap, see [3]. > > > > Any thoughts or feedback is more than welcome! > > > > Greetings, > > Matthias > > > > [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12325082 > > [2] > > > https://aerogear.org/news/2014/12/03/aerogear-unified-push-alpha1-is-out/index.html > > [3] https://github.com/aerogear/aerogear.org/pull/441 > > > > > > -- > > 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/20141213/018a9321/attachment.html From matzew at apache.org Sat Dec 13 02:21:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 13 Dec 2014 08:21:28 +0100 Subject: [aerogear-dev] AeroGear notifications In-Reply-To: References: Message-ID: ah, glad the issue is gone! On Saturday, December 13, 2014, Danijel Kecman wrote: > Hi Matthias, > > I have upgraded the aerogear instance and the problem went away. I recall > now that I had upgraded the SDKs. It might be it, or, I suspect, it might > be just a bad connection on the OpenShift side, me bing in the EU ant the > server on the US west. > > Thank you, > Danijel > > On Fri, Dec 12, 2014 at 9:15 AM, Matthias Wessendorf > wrote: >> >> Hey Danijel, >> >> did you try sending messages using the UI, on the Unified Push Server ? >> >> On Thu, Dec 11, 2014 at 1:11 PM, Danijel Kecman > > wrote: >> >>> Hi, >>> >>> I have a test env where my AeroGear is hosted at OpenShift. Suddenly I >>> am not receiving any notifications, neither on my Android nor my iOS >>> devices. I did not change anything in the code that could cause this. >>> AeroGear on OpenShift responds properly. My .NET and Java code that does >>> the calls to the AeroGear REST responds with success. Does anyone have >>> similar experience? >>> >>> Thanks, >>> Danijel >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.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/20141213/cf2a17d6/attachment.html From matzew at apache.org Sat Dec 13 06:19:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 13 Dec 2014 12:19:10 +0100 Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <547301999.1047005.1418418726344.JavaMail.zimbra@redhat.com> References: <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> <1418367675134.24f18f08@Nodemailer> <547301999.1047005.1418418726344.JavaMail.zimbra@redhat.com> Message-ID: Wow, that looks really good, Andres! great job! I ran it locally and the first impression was, again, WOW :) I noticed one minor issue, related to the JBoss/Red Hat snippets. Your branch still reaches out to static.jboss.org. We recently changed that: https://github.com/aerogear/aerogear.org/pull/439 that yeah, that's just minor - but I think it's perhaps easier to pick it up now, instead of later on the road. Again, great job. PLUS PLUS On Fri, Dec 12, 2014 at 10:12 PM, Andres Galante wrote: > > I started implementation today. You can follow the progress here: > > https://github.com/andresgalante/aerogear.org/tree/new-design > > > > ----- Original Message ----- > From: "Daniel Bevenius" > To: "AeroGear Developer Mailing List" > Sent: Friday, December 12, 2014 4:13:23 AM > Subject: Re: [aerogear-dev] Website structural changes and implementation > > +1 > > fredag 12 december 2014 skrev Bruno Oliveira < bruno at abstractj.org >: > > > +1 go ahead > > ? > abstractj > PGP: 0x84DC9914 > > > > > On Thu, Dec 11, 2014 at 5:27 PM, Andres Galante < agalante at redhat.com > > wrote: > > > > > Hi! > > I've made all the changes and other small things, and it looks like this: > > http://andresgalante.com/aerogearwebsite/ > > Should I start integration with Jekyll? > > > > ----- Original Message ----- > From: "Luk?? Fry?" < lukas.fryc at gmail.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Sent: Thursday, December 11, 2014 12:24:23 PM > Subject: Re: [aerogear-dev] Website structural changes and implementation > > Hey Andres, > > all suggested changes sounds good to me personally > > +1 for sidebar on the left, seems like more straight-forward way to > communicate the page structure then the right version > > On Thu, Dec 11, 2014 at 2:06 PM, Andres Galante < agalante at redhat.com > > wrote: > > > Sorry there is one more: > > - Sidebar and content area: Should we have the sidebar on the left like > ionic [1] or on the right like bootstrap [2] ? > > [1] http://ionicframework.com/docs/components/#header > [2] http://getbootstrap.com/css/ > > I can send images of how our website look with both versions if needed. > > > ----- Original Message ----- > From: "Andres Galante" < agalante at redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Sent: Thursday, December 11, 2014 10:02:28 AM > Subject: [aerogear-dev] Website structural changes and implementation > > Hi! > > Since the main discussion on the website now is weather what color to use > I think we can move to implementation. Styling and color changes are not a > blocker. > > But before that, I want to make sure we have a solid structure. These are > three concerns I've heard that we can discuss: > > - Roadmaps should be feature specific instead of platform specific > http://andresgalante.com/aerogearwebsite/roadmap.html > > - We should move Demos and Guides under "Get Started" > > - I've changed main title to make sure the right audience (enterprise > mobile developers) know this is a place for them. > Now it reads: "Bringing mobile and enterprise together." is it ok? > > What do you think? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141213/18f2355d/attachment-0001.html From daniel.bevenius at gmail.com Sun Dec 14 09:49:33 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Sun, 14 Dec 2014 15:49:33 +0100 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20141215 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141214/ed65cf4e/attachment.html From pstribny at redhat.com Mon Dec 15 03:20:43 2014 From: pstribny at redhat.com (Petr Stribny) Date: Mon, 15 Dec 2014 03:20:43 -0500 (EST) Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> References: <266736271.905177.1418302948268.JavaMail.zimbra@redhat.com> <741977381.905408.1418303190781.JavaMail.zimbra@redhat.com> <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> Message-ID: <11019949.14870494.1418631643387.JavaMail.zimbra@redhat.com> Hi Andres, I really like the new design, so much better than the previous one! But for some reason I dislike the position of the search field and Github link. It is OK when you scroll down so that it becomes a part of navigation bar, but when you scroll just a little, it does not look right to me. This is just my opinion of course. Keep up the good work! --Petr ----- Original Message ----- From: "Andres Galante" To: "AeroGear Developer Mailing List" Sent: Thursday, 11 December, 2014 8:27:18 PM Subject: Re: [aerogear-dev] Website structural changes and implementation Hi! I've made all the changes and other small things, and it looks like this: http://andresgalante.com/aerogearwebsite/ Should I start integration with Jekyll? ----- Original Message ----- From: "Luk?? Fry?" To: "AeroGear Developer Mailing List" Sent: Thursday, December 11, 2014 12:24:23 PM Subject: Re: [aerogear-dev] Website structural changes and implementation Hey Andres, all suggested changes sounds good to me personally +1 for sidebar on the left, seems like more straight-forward way to communicate the page structure then the right version On Thu, Dec 11, 2014 at 2:06 PM, Andres Galante < agalante at redhat.com > wrote: Sorry there is one more: - Sidebar and content area: Should we have the sidebar on the left like ionic [1] or on the right like bootstrap [2] ? [1] http://ionicframework.com/docs/components/#header [2] http://getbootstrap.com/css/ I can send images of how our website look with both versions if needed. ----- Original Message ----- From: "Andres Galante" < agalante at redhat.com > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Thursday, December 11, 2014 10:02:28 AM Subject: [aerogear-dev] Website structural changes and implementation Hi! Since the main discussion on the website now is weather what color to use I think we can move to implementation. Styling and color changes are not a blocker. But before that, I want to make sure we have a solid structure. These are three concerns I've heard that we can discuss: - Roadmaps should be feature specific instead of platform specific http://andresgalante.com/aerogearwebsite/roadmap.html - We should move Demos and Guides under "Get Started" - I've changed main title to make sure the right audience (enterprise mobile developers) know this is a place for them. Now it reads: "Bringing mobile and enterprise together." is it ok? What do you think? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 edewit at redhat.com Mon Dec 15 04:11:36 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 15 Dec 2014 10:11:36 +0100 Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <11019949.14870494.1418631643387.JavaMail.zimbra@redhat.com> References: <266736271.905177.1418302948268.JavaMail.zimbra@redhat.com> <741977381.905408.1418303190781.JavaMail.zimbra@redhat.com> <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> <11019949.14870494.1418631643387.JavaMail.zimbra@redhat.com> Message-ID: <6C78C353-426B-459C-832E-23148C392B1F@redhat.com> One more thing that jumped into my mind, right now on our website we don?t use the apple logo for iOS because there was a trademark on this. We should maybe check if this is still the case and maybe also for the windows logo? From bruno at abstractj.org Mon Dec 15 07:24:22 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Dec 2014 10:24:22 -0200 Subject: [aerogear-dev] Our guides on AeroGear Message-ID: <20141215122422.GA65081@abstractj.org> Good morning my friends, I would like to ask you a favor if possible. Include a section "requirements" in each guide on AeroGear. Why why why? Some things are not very obvious to newcomers from other technologies, like me. So at least the minimum about what must be configured/instaled/dependencies would be super nice. Thanks in advance. -- abstractj PGP: 0x84DC9914 From agalante at redhat.com Mon Dec 15 08:00:24 2014 From: agalante at redhat.com (Andres Galante) Date: Mon, 15 Dec 2014 08:00:24 -0500 (EST) Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <11019949.14870494.1418631643387.JavaMail.zimbra@redhat.com> References: <266736271.905177.1418302948268.JavaMail.zimbra@redhat.com> <741977381.905408.1418303190781.JavaMail.zimbra@redhat.com> <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> <11019949.14870494.1418631643387.JavaMail.zimbra@redhat.com> Message-ID: <1567223588.1123363.1418648424511.JavaMail.zimbra@redhat.com> Hi Petr, I really like that part of the deisng, but it seems its not very good since you are not the first to dislike it. I'll try something else. ----- Original Message ----- From: "Petr Stribny" To: "AeroGear Developer Mailing List" Sent: Monday, December 15, 2014 5:20:43 AM Subject: Re: [aerogear-dev] Website structural changes and implementation Hi Andres, I really like the new design, so much better than the previous one! But for some reason I dislike the position of the search field and Github link. It is OK when you scroll down so that it becomes a part of navigation bar, but when you scroll just a little, it does not look right to me. This is just my opinion of course. Keep up the good work! --Petr ----- Original Message ----- From: "Andres Galante" To: "AeroGear Developer Mailing List" Sent: Thursday, 11 December, 2014 8:27:18 PM Subject: Re: [aerogear-dev] Website structural changes and implementation Hi! I've made all the changes and other small things, and it looks like this: http://andresgalante.com/aerogearwebsite/ Should I start integration with Jekyll? ----- Original Message ----- From: "Luk?? Fry?" To: "AeroGear Developer Mailing List" Sent: Thursday, December 11, 2014 12:24:23 PM Subject: Re: [aerogear-dev] Website structural changes and implementation Hey Andres, all suggested changes sounds good to me personally +1 for sidebar on the left, seems like more straight-forward way to communicate the page structure then the right version On Thu, Dec 11, 2014 at 2:06 PM, Andres Galante < agalante at redhat.com > wrote: Sorry there is one more: - Sidebar and content area: Should we have the sidebar on the left like ionic [1] or on the right like bootstrap [2] ? [1] http://ionicframework.com/docs/components/#header [2] http://getbootstrap.com/css/ I can send images of how our website look with both versions if needed. ----- Original Message ----- From: "Andres Galante" < agalante at redhat.com > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Thursday, December 11, 2014 10:02:28 AM Subject: [aerogear-dev] Website structural changes and implementation Hi! Since the main discussion on the website now is weather what color to use I think we can move to implementation. Styling and color changes are not a blocker. But before that, I want to make sure we have a solid structure. These are three concerns I've heard that we can discuss: - Roadmaps should be feature specific instead of platform specific http://andresgalante.com/aerogearwebsite/roadmap.html - We should move Demos and Guides under "Get Started" - I've changed main title to make sure the right audience (enterprise mobile developers) know this is a place for them. Now it reads: "Bringing mobile and enterprise together." is it ok? What do you think? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 From agalante at redhat.com Mon Dec 15 08:01:33 2014 From: agalante at redhat.com (Andres Galante) Date: Mon, 15 Dec 2014 08:01:33 -0500 (EST) Subject: [aerogear-dev] Website structural changes and implementation In-Reply-To: <6C78C353-426B-459C-832E-23148C392B1F@redhat.com> References: <266736271.905177.1418302948268.JavaMail.zimbra@redhat.com> <741977381.905408.1418303190781.JavaMail.zimbra@redhat.com> <815761180.946736.1418326038095.JavaMail.zimbra@redhat.com> <11019949.14870494.1418631643387.JavaMail.zimbra@redhat.com> <6C78C353-426B-459C-832E-23148C392B1F@redhat.com> Message-ID: <1662172464.1123661.1418648493000.JavaMail.zimbra@redhat.com> ok, I'll try something else :) maybe I can do something without using the logos thanks for the heads up ----- Original Message ----- From: "Erik Jan de Wit" To: "AeroGear Developer Mailing List" Sent: Monday, December 15, 2014 6:11:36 AM Subject: Re: [aerogear-dev] Website structural changes and implementation One more thing that jumped into my mind, right now on our website we don?t use the apple logo for iOS because there was a trademark on this. We should maybe check if this is still the case and maybe also for the windows logo? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Mon Dec 15 08:09:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 14:09:23 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs Message-ID: Hi team, while thinking about restructuring our roadmaps, I was wondering about our existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more feature driven, but that requires some more thoughts/changes? However, here is what I am wondering about... Most of our roadmaps we link to from [1], are really just pointing to different JIRAs. Let's take one example, UPS: https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ Basically all info on the above page is present in JIRA (including the 'archived' roadmap of older releases). Since JIRA should be the central tool for planing releases, features and future versions, I think that our roadmap docs are not adding too much value, since they repeat info that is available on a different place (JIRA). Also, maintaining the roadmaps is tedious: You make a change on the actual JIRA (e.g. move the date of a release or add a new feature). To keep the roadmap up-to-date, you put the same info on the roadmap doc and send a PR. Can we remove these roadmap docs? For UPS that would mean, that the link on [1] would go against: https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel instead of here: https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ -Matthias [1] https://aerogear.org/docs/planning/ -- 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/20141215/468e547a/attachment.html From scm.blanc at gmail.com Mon Dec 15 08:15:37 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 15 Dec 2014 14:15:37 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: Message-ID: +1 to not duplicate the work regarding jiras/the roadmap on the website. But in the same time, I think it's important to keep on the site some info for the future releases, less concrete, more like our "vision" / themes that we would like to cover. Can be resumed to only 3 or 4 bullets points. On Mon, Dec 15, 2014 at 2:09 PM, Matthias Wessendorf wrote: > > Hi team, > > while thinking about restructuring our roadmaps, I was wondering about our > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more > feature driven, but that requires some more thoughts/changes? > > However, here is what I am wondering about... > > Most of our roadmaps we link to from [1], are really just pointing to > different JIRAs. > > > Let's take one example, UPS: > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > Basically all info on the above page is present in JIRA (including the > 'archived' roadmap of older releases). Since JIRA should be the central > tool for planing releases, features and future versions, I think that our > roadmap docs are not adding too much value, since they repeat info that is > available on a different place (JIRA). > > Also, maintaining the roadmaps is tedious: You make a change on the actual > JIRA (e.g. move the date of a release or add a new feature). To keep the > roadmap up-to-date, you put the same info on the roadmap doc and send a PR. > > > Can we remove these roadmap docs? > > For UPS that would mean, that the link on [1] would go against: > > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel > > instead of here: > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > -Matthias > > [1] https://aerogear.org/docs/planning/ > > > -- > 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/20141215/2c0f5f97/attachment-0001.html From daniel.bevenius at gmail.com Mon Dec 15 08:15:59 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 15 Dec 2014 14:15:59 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: Message-ID: > Also, maintaining the roadmaps is tedious: You make a change on the actual JIRA (e.g. move the date of a release or add a new feature). To keep the roadmap up-to-date, you put the same info on the roadmap doc and send a PR I agree. The only concern for me would be that it might not be as clear for users coming to our site that are not used to JIRA. On 15 December 2014 at 14:09, Matthias Wessendorf wrote: > Hi team, > > while thinking about restructuring our roadmaps, I was wondering about our > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more > feature driven, but that requires some more thoughts/changes? > > However, here is what I am wondering about... > > Most of our roadmaps we link to from [1], are really just pointing to > different JIRAs. > > > Let's take one example, UPS: > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > Basically all info on the above page is present in JIRA (including the > 'archived' roadmap of older releases). Since JIRA should be the central > tool for planing releases, features and future versions, I think that our > roadmap docs are not adding too much value, since they repeat info that is > available on a different place (JIRA). > > Also, maintaining the roadmaps is tedious: You make a change on the actual > JIRA (e.g. move the date of a release or add a new feature). To keep the > roadmap up-to-date, you put the same info on the roadmap doc and send a PR. > > > Can we remove these roadmap docs? > > For UPS that would mean, that the link on [1] would go against: > > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel > > instead of here: > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > -Matthias > > [1] https://aerogear.org/docs/planning/ > > > -- > 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/20141215/58680a80/attachment.html From matzew at apache.org Mon Dec 15 08:22:04 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 14:22:04 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: Message-ID: On Mon, Dec 15, 2014 at 2:15 PM, Sebastien Blanc wrote: > > +1 to not duplicate the work regarding jiras/the roadmap on the website. > But in the same time, I think it's important to keep on the site some info > for the future releases, less concrete, more like our "vision" / themes > that we would like to cover. Can be resumed to only 3 or 4 bullets points. > yes, I was not saying remove all of the roadmaps. The plan is to re-org. the current structure. Turn it more into something that is feature based * AeroGear OAuth2 - 1.0.0 (Janurary) LINK to details * AeroGear Sync - 1.0.0 (April) LINK to details * AeroGear SOME_FEATURE - 1.0.0 (SOME MONTH) LINK to details That will give an understand of what's coming, overall. The remove of the duplicating roadmap docs is just one thing > > > On Mon, Dec 15, 2014 at 2:09 PM, Matthias Wessendorf > wrote: > >> Hi team, >> >> while thinking about restructuring our roadmaps, I was wondering about >> our existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more >> feature driven, but that requires some more thoughts/changes? >> >> However, here is what I am wondering about... >> >> Most of our roadmaps we link to from [1], are really just pointing to >> different JIRAs. >> >> >> Let's take one example, UPS: >> https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >> >> Basically all info on the above page is present in JIRA (including the >> 'archived' roadmap of older releases). Since JIRA should be the central >> tool for planing releases, features and future versions, I think that our >> roadmap docs are not adding too much value, since they repeat info that is >> available on a different place (JIRA). >> >> Also, maintaining the roadmaps is tedious: You make a change on the >> actual JIRA (e.g. move the date of a release or add a new feature). To keep >> the roadmap up-to-date, you put the same info on the roadmap doc and send a >> PR. >> >> >> Can we remove these roadmap docs? >> >> For UPS that would mean, that the link on [1] would go against: >> >> https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel >> >> instead of here: >> https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >> >> -Matthias >> >> [1] https://aerogear.org/docs/planning/ >> >> >> -- >> 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/20141215/b90a96cc/attachment.html From matzew at apache.org Mon Dec 15 08:22:41 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 14:22:41 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: Message-ID: On Mon, Dec 15, 2014 at 2:15 PM, Daniel Bevenius wrote: > > > Also, maintaining the roadmaps is tedious: You make a change on the > actual JIRA (e.g. move the date of a release or add a new feature). To keep > the roadmap up-to-date, you put the same info on the roadmap doc and send a > PR > I agree. The only concern for me would be that it might not be as clear > for users coming to our site that are not used to JIRA. > the versions page is pretty easy to read :) Version # and a date. + a link to dive into details > > On 15 December 2014 at 14:09, Matthias Wessendorf > wrote: > >> Hi team, >> >> while thinking about restructuring our roadmaps, I was wondering about >> our existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more >> feature driven, but that requires some more thoughts/changes? >> >> However, here is what I am wondering about... >> >> Most of our roadmaps we link to from [1], are really just pointing to >> different JIRAs. >> >> >> Let's take one example, UPS: >> https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >> >> Basically all info on the above page is present in JIRA (including the >> 'archived' roadmap of older releases). Since JIRA should be the central >> tool for planing releases, features and future versions, I think that our >> roadmap docs are not adding too much value, since they repeat info that is >> available on a different place (JIRA). >> >> Also, maintaining the roadmaps is tedious: You make a change on the >> actual JIRA (e.g. move the date of a release or add a new feature). To keep >> the roadmap up-to-date, you put the same info on the roadmap doc and send a >> PR. >> >> >> Can we remove these roadmap docs? >> >> For UPS that would mean, that the link on [1] would go against: >> >> https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel >> >> instead of here: >> https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >> >> -Matthias >> >> [1] https://aerogear.org/docs/planning/ >> >> >> -- >> 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/20141215/961b6acf/attachment.html From bruno at abstractj.org Mon Dec 15 08:25:55 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Dec 2014 11:25:55 -0200 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: Message-ID: <20141215132555.GA88292@abstractj.org> Speaking from the security side of the things, to me is impossible to have a feature driven roadmap, because it's a cross cutting concern. About removing the roadmap from website, as long as we make it clear por people outside AeroGear, I'm fine. On 2014-12-15, Matthias Wessendorf wrote: > Hi team, > > while thinking about restructuring our roadmaps, I was wondering about our > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more > feature driven, but that requires some more thoughts/changes? > > However, here is what I am wondering about... > > Most of our roadmaps we link to from [1], are really just pointing to > different JIRAs. > > > Let's take one example, UPS: > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > Basically all info on the above page is present in JIRA (including the > 'archived' roadmap of older releases). Since JIRA should be the central > tool for planing releases, features and future versions, I think that our > roadmap docs are not adding too much value, since they repeat info that is > available on a different place (JIRA). > > Also, maintaining the roadmaps is tedious: You make a change on the actual > JIRA (e.g. move the date of a release or add a new feature). To keep the > roadmap up-to-date, you put the same info on the roadmap doc and send a PR. > > > Can we remove these roadmap docs? > > For UPS that would mean, that the link on [1] would go against: > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel > > instead of here: > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > -Matthias > > [1] https://aerogear.org/docs/planning/ > > > -- > 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 Mon Dec 15 08:31:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 14:31:44 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: <20141215132555.GA88292@abstractj.org> References: <20141215132555.GA88292@abstractj.org> Message-ID: On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira wrote: > > Speaking from the security side of the things, to me is impossible to > have a feature driven roadmap, because it's a cross cutting concern. > right :-) looking at [1] I see different types of roadmaps 1) Project roadmap 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) 3) cross cutting concerns (e.g. security) 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) And that's fine :) For now, I'd really just like to get rid of the pages that basically duplicate info, available on JIRA :-) > > About removing the roadmap from website, as long as we make it clear > por people outside AeroGear, I'm fine. > > On 2014-12-15, Matthias Wessendorf wrote: > > Hi team, > > > > while thinking about restructuring our roadmaps, I was wondering about > our > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more > > feature driven, but that requires some more thoughts/changes? > > > > However, here is what I am wondering about... > > > > Most of our roadmaps we link to from [1], are really just pointing to > > different JIRAs. > > > > > > Let's take one example, UPS: > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > Basically all info on the above page is present in JIRA (including the > > 'archived' roadmap of older releases). Since JIRA should be the central > > tool for planing releases, features and future versions, I think that our > > roadmap docs are not adding too much value, since they repeat info that > is > > available on a different place (JIRA). > > > > Also, maintaining the roadmaps is tedious: You make a change on the > actual > > JIRA (e.g. move the date of a release or add a new feature). To keep the > > roadmap up-to-date, you put the same info on the roadmap doc and send a > PR. > > > > > > Can we remove these roadmap docs? > > > > For UPS that would mean, that the link on [1] would go against: > > > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel > > > > instead of here: > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > -Matthias > > > > [1] https://aerogear.org/docs/planning/ > > > > > > -- > > 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/20141215/886c7c5a/attachment.html From bruno at abstractj.org Mon Dec 15 08:40:39 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Dec 2014 11:40:39 -0200 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: <20141215132555.GA88292@abstractj.org> Message-ID: <20141215134039.GA95353@abstractj.org> Alright, let's think about the following scenario. I'm a newcomer, going aerogear.org to learn more about AeroGear and want to know what's planned for the future releases. Where should I look? On 2014-12-15, Matthias Wessendorf wrote: > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira wrote: > > > > Speaking from the security side of the things, to me is impossible to > > have a feature driven roadmap, because it's a cross cutting concern. > > > > right :-) > > looking at [1] I see different types of roadmaps > > 1) Project roadmap > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) > 3) cross cutting concerns (e.g. security) > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) > > > And that's fine :) For now, I'd really just like to get rid of the pages > that basically duplicate info, available on JIRA :-) > > > > > > > > About removing the roadmap from website, as long as we make it clear > > por people outside AeroGear, I'm fine. > > > > On 2014-12-15, Matthias Wessendorf wrote: > > > Hi team, > > > > > > while thinking about restructuring our roadmaps, I was wondering about > > our > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more > > > feature driven, but that requires some more thoughts/changes? > > > > > > However, here is what I am wondering about... > > > > > > Most of our roadmaps we link to from [1], are really just pointing to > > > different JIRAs. > > > > > > > > > Let's take one example, UPS: > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > Basically all info on the above page is present in JIRA (including the > > > 'archived' roadmap of older releases). Since JIRA should be the central > > > tool for planing releases, features and future versions, I think that our > > > roadmap docs are not adding too much value, since they repeat info that > > is > > > available on a different place (JIRA). > > > > > > Also, maintaining the roadmaps is tedious: You make a change on the > > actual > > > JIRA (e.g. move the date of a release or add a new feature). To keep the > > > roadmap up-to-date, you put the same info on the roadmap doc and send a > > PR. > > > > > > > > > Can we remove these roadmap docs? > > > > > > For UPS that would mean, that the link on [1] would go against: > > > > > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel > > > > > > instead of here: > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > -Matthias > > > > > > [1] https://aerogear.org/docs/planning/ > > > > > > > > > -- > > > 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 > _______________________________________________ > 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 Mon Dec 15 09:05:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 15:05:16 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: <20141215134039.GA95353@abstractj.org> References: <20141215132555.GA88292@abstractj.org> <20141215134039.GA95353@abstractj.org> Message-ID: Hey, that's what I am currently looking at - by doing the analysis of the site, I noticed that our current roadmap docs just duplicate info from JIRA First step: replace existing roadmaps with links to JIRAs, where possible. Next step: re-think the entire roadmaps section. I am currently on that, and it's not 100% yet clear, what's best. Once I have more on this, I will share thoughts On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira wrote: > > Alright, let's think about the following scenario. I'm a newcomer, going > aerogear.org to learn more about AeroGear and want to know what's planned > for the future > releases. Where should I look? > > On 2014-12-15, Matthias Wessendorf wrote: > > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira > wrote: > > > > > > Speaking from the security side of the things, to me is impossible to > > > have a feature driven roadmap, because it's a cross cutting concern. > > > > > > > right :-) > > > > looking at [1] I see different types of roadmaps > > > > 1) Project roadmap > > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) > > 3) cross cutting concerns (e.g. security) > > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) > > > > > > And that's fine :) For now, I'd really just like to get rid of the pages > > that basically duplicate info, available on JIRA :-) > > > > > > > > > > > > > > About removing the roadmap from website, as long as we make it clear > > > por people outside AeroGear, I'm fine. > > > > > > On 2014-12-15, Matthias Wessendorf wrote: > > > > Hi team, > > > > > > > > while thinking about restructuring our roadmaps, I was wondering > about > > > our > > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps > more > > > > feature driven, but that requires some more thoughts/changes? > > > > > > > > However, here is what I am wondering about... > > > > > > > > Most of our roadmaps we link to from [1], are really just pointing to > > > > different JIRAs. > > > > > > > > > > > > Let's take one example, UPS: > > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > > > Basically all info on the above page is present in JIRA (including > the > > > > 'archived' roadmap of older releases). Since JIRA should be the > central > > > > tool for planing releases, features and future versions, I think > that our > > > > roadmap docs are not adding too much value, since they repeat info > that > > > is > > > > available on a different place (JIRA). > > > > > > > > Also, maintaining the roadmaps is tedious: You make a change on the > > > actual > > > > JIRA (e.g. move the date of a release or add a new feature). To keep > the > > > > roadmap up-to-date, you put the same info on the roadmap doc and > send a > > > PR. > > > > > > > > > > > > Can we remove these roadmap docs? > > > > > > > > For UPS that would mean, that the link on [1] would go against: > > > > > > > > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel > > > > > > > > instead of here: > > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > > > -Matthias > > > > > > > > [1] https://aerogear.org/docs/planning/ > > > > > > > > > > > > -- > > > > 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 > > > _______________________________________________ > > 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/20141215/48cafdcc/attachment-0001.html From daniel.bevenius at gmail.com Mon Dec 15 09:08:31 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 15 Dec 2014 15:08:31 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: <20141215132555.GA88292@abstractj.org> <20141215134039.GA95353@abstractj.org> Message-ID: >First step: replace existing roadmaps with links to JIRAs, where possible. >Next step: re-think the entire roadmaps section. I am currently on that, and it's not 100% yet clear, what's best. Once I have more on this, I will share thoughts Sounds good! On 15 December 2014 at 15:05, Matthias Wessendorf wrote: > Hey, > > that's what I am currently looking at - by doing the analysis of the site, > I noticed that our current roadmap docs just duplicate info from JIRA > > First step: replace existing roadmaps with links to JIRAs, where possible. > > Next step: re-think the entire roadmaps section. I am currently on that, > and it's not 100% yet clear, what's best. Once I have more on this, I will > share thoughts > > > > On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira > wrote: >> >> Alright, let's think about the following scenario. I'm a newcomer, going >> aerogear.org to learn more about AeroGear and want to know what's >> planned for the future >> releases. Where should I look? >> >> On 2014-12-15, Matthias Wessendorf wrote: >> > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira >> wrote: >> > > >> > > Speaking from the security side of the things, to me is impossible to >> > > have a feature driven roadmap, because it's a cross cutting concern. >> > > >> > >> > right :-) >> > >> > looking at [1] I see different types of roadmaps >> > >> > 1) Project roadmap >> > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) >> > 3) cross cutting concerns (e.g. security) >> > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) >> > >> > >> > And that's fine :) For now, I'd really just like to get rid of the pages >> > that basically duplicate info, available on JIRA :-) >> > >> > >> > >> > >> > > >> > > About removing the roadmap from website, as long as we make it clear >> > > por people outside AeroGear, I'm fine. >> > > >> > > On 2014-12-15, Matthias Wessendorf wrote: >> > > > Hi team, >> > > > >> > > > while thinking about restructuring our roadmaps, I was wondering >> about >> > > our >> > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps >> more >> > > > feature driven, but that requires some more thoughts/changes? >> > > > >> > > > However, here is what I am wondering about... >> > > > >> > > > Most of our roadmaps we link to from [1], are really just pointing >> to >> > > > different JIRAs. >> > > > >> > > > >> > > > Let's take one example, UPS: >> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >> > > > >> > > > Basically all info on the above page is present in JIRA (including >> the >> > > > 'archived' roadmap of older releases). Since JIRA should be the >> central >> > > > tool for planing releases, features and future versions, I think >> that our >> > > > roadmap docs are not adding too much value, since they repeat info >> that >> > > is >> > > > available on a different place (JIRA). >> > > > >> > > > Also, maintaining the roadmaps is tedious: You make a change on the >> > > actual >> > > > JIRA (e.g. move the date of a release or add a new feature). To >> keep the >> > > > roadmap up-to-date, you put the same info on the roadmap doc and >> send a >> > > PR. >> > > > >> > > > >> > > > Can we remove these roadmap docs? >> > > > >> > > > For UPS that would mean, that the link on [1] would go against: >> > > > >> > > >> https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel >> > > > >> > > > instead of here: >> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >> > > > >> > > > -Matthias >> > > > >> > > > [1] https://aerogear.org/docs/planning/ >> > > > >> > > > >> > > > -- >> > > > 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 >> >> > _______________________________________________ >> > 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/20141215/8cea5b40/attachment.html From agalante at redhat.com Mon Dec 15 09:17:56 2014 From: agalante at redhat.com (Andres Galante) Date: Mon, 15 Dec 2014 09:17:56 -0500 (EST) Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: <20141215132555.GA88292@abstractj.org> <20141215134039.GA95353@abstractj.org> Message-ID: <90466273.1130732.1418653076247.JavaMail.zimbra@redhat.com> Can't we have some kind of aggregator that reads the roadmaps from JIRA and print it on the website? ----- Original Message ----- From: "Daniel Bevenius" To: "AeroGear Developer Mailing List" Sent: Monday, December 15, 2014 11:08:31 AM Subject: Re: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs > First step: replace existing roadmaps with links to JIRAs, where possible. >Next step: re-think the entire roadmaps section. I am currently on that, and it's not 100% yet clear, what's best. Once I have more on this, I will share thoughts Sounds good! On 15 December 2014 at 15:05, Matthias Wessendorf < matzew at apache.org > wrote: Hey, that's what I am currently looking at - by doing the analysis of the site, I noticed that our current roadmap docs just duplicate info from JIRA First step: replace existing roadmaps with links to JIRAs, where possible. Next step: re-think the entire roadmaps section. I am currently on that, and it's not 100% yet clear, what's best. Once I have more on this, I will share thoughts On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira < bruno at abstractj.org > wrote: Alright, let's think about the following scenario. I'm a newcomer, going aerogear.org to learn more about AeroGear and want to know what's planned for the future releases. Where should I look? On 2014-12-15, Matthias Wessendorf wrote: > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira < bruno at abstractj.org > wrote: > > > > Speaking from the security side of the things, to me is impossible to > > have a feature driven roadmap, because it's a cross cutting concern. > > > > right :-) > > looking at [1] I see different types of roadmaps > > 1) Project roadmap > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) > 3) cross cutting concerns (e.g. security) > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) > > > And that's fine :) For now, I'd really just like to get rid of the pages > that basically duplicate info, available on JIRA :-) > > > > > > > > About removing the roadmap from website, as long as we make it clear > > por people outside AeroGear, I'm fine. > > > > On 2014-12-15, Matthias Wessendorf wrote: > > > Hi team, > > > > > > while thinking about restructuring our roadmaps, I was wondering about > > our > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more > > > feature driven, but that requires some more thoughts/changes? > > > > > > However, here is what I am wondering about... > > > > > > Most of our roadmaps we link to from [1], are really just pointing to > > > different JIRAs. > > > > > > > > > Let's take one example, UPS: > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > Basically all info on the above page is present in JIRA (including the > > > 'archived' roadmap of older releases). Since JIRA should be the central > > > tool for planing releases, features and future versions, I think that our > > > roadmap docs are not adding too much value, since they repeat info that > > is > > > available on a different place (JIRA). > > > > > > Also, maintaining the roadmaps is tedious: You make a change on the > > actual > > > JIRA (e.g. move the date of a release or add a new feature). To keep the > > > roadmap up-to-date, you put the same info on the roadmap doc and send a > > PR. > > > > > > > > > Can we remove these roadmap docs? > > > > > > For UPS that would mean, that the link on [1] would go against: > > > > > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel > > > > > > instead of here: > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > -Matthias > > > > > > [1] https://aerogear.org/docs/planning/ > > > > > > > > > -- > > > 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 > _______________________________________________ > 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 From matzew at apache.org Mon Dec 15 09:21:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 15:21:28 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: <20141215132555.GA88292@abstractj.org> <20141215134039.GA95353@abstractj.org> Message-ID: My current thought is, that on https://aerogear.org/docs/planning/ we should not just have link. Straight on the page I'd like to list the next planed features: *OAuth2 * Sync *Offline Each item has a bit of details. and underneath these features, I'd like to place links to the JIRAs of the different modules, like Security, Cordova etc. Basically like it is today (with the little different of pointing to JIRA, instead of our own roadmap docs, where possible). Let me PR this... That is just a first step. more to come soon :) On Mon, Dec 15, 2014 at 3:08 PM, Daniel Bevenius wrote: > > >First step: replace existing roadmaps with links to JIRAs, where > possible. > > >Next step: re-think the entire roadmaps section. I am currently on that, > and it's not 100% yet clear, what's best. Once I have more on this, I will > share thoughts > Sounds good! > > On 15 December 2014 at 15:05, Matthias Wessendorf > wrote: > >> Hey, >> >> that's what I am currently looking at - by doing the analysis of the >> site, I noticed that our current roadmap docs just duplicate info from JIRA >> >> First step: replace existing roadmaps with links to JIRAs, where possible. >> >> Next step: re-think the entire roadmaps section. I am currently on that, >> and it's not 100% yet clear, what's best. Once I have more on this, I will >> share thoughts >> >> >> >> On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira >> wrote: >>> >>> Alright, let's think about the following scenario. I'm a newcomer, going >>> aerogear.org to learn more about AeroGear and want to know what's >>> planned for the future >>> releases. Where should I look? >>> >>> On 2014-12-15, Matthias Wessendorf wrote: >>> > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira >>> wrote: >>> > > >>> > > Speaking from the security side of the things, to me is impossible to >>> > > have a feature driven roadmap, because it's a cross cutting concern. >>> > > >>> > >>> > right :-) >>> > >>> > looking at [1] I see different types of roadmaps >>> > >>> > 1) Project roadmap >>> > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) >>> > 3) cross cutting concerns (e.g. security) >>> > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) >>> > >>> > >>> > And that's fine :) For now, I'd really just like to get rid of the >>> pages >>> > that basically duplicate info, available on JIRA :-) >>> > >>> > >>> > >>> > >>> > > >>> > > About removing the roadmap from website, as long as we make it clear >>> > > por people outside AeroGear, I'm fine. >>> > > >>> > > On 2014-12-15, Matthias Wessendorf wrote: >>> > > > Hi team, >>> > > > >>> > > > while thinking about restructuring our roadmaps, I was wondering >>> about >>> > > our >>> > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps >>> more >>> > > > feature driven, but that requires some more thoughts/changes? >>> > > > >>> > > > However, here is what I am wondering about... >>> > > > >>> > > > Most of our roadmaps we link to from [1], are really just pointing >>> to >>> > > > different JIRAs. >>> > > > >>> > > > >>> > > > Let's take one example, UPS: >>> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >>> > > > >>> > > > Basically all info on the above page is present in JIRA (including >>> the >>> > > > 'archived' roadmap of older releases). Since JIRA should be the >>> central >>> > > > tool for planing releases, features and future versions, I think >>> that our >>> > > > roadmap docs are not adding too much value, since they repeat info >>> that >>> > > is >>> > > > available on a different place (JIRA). >>> > > > >>> > > > Also, maintaining the roadmaps is tedious: You make a change on the >>> > > actual >>> > > > JIRA (e.g. move the date of a release or add a new feature). To >>> keep the >>> > > > roadmap up-to-date, you put the same info on the roadmap doc and >>> send a >>> > > PR. >>> > > > >>> > > > >>> > > > Can we remove these roadmap docs? >>> > > > >>> > > > For UPS that would mean, that the link on [1] would go against: >>> > > > >>> > > >>> https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel >>> > > > >>> > > > instead of here: >>> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >>> > > > >>> > > > -Matthias >>> > > > >>> > > > [1] https://aerogear.org/docs/planning/ >>> > > > >>> > > > >>> > > > -- >>> > > > 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 >>> >>> > _______________________________________________ >>> > 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/20141215/8e87f50b/attachment-0001.html From matzew at apache.org Mon Dec 15 09:23:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 15:23:22 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: <90466273.1130732.1418653076247.JavaMail.zimbra@redhat.com> References: <20141215132555.GA88292@abstractj.org> <20141215134039.GA95353@abstractj.org> <90466273.1130732.1418653076247.JavaMail.zimbra@redhat.com> Message-ID: On Mon, Dec 15, 2014 at 3:17 PM, Andres Galante wrote: > > Can't we have some kind of aggregator that reads the roadmaps from JIRA > and print it on the website? > Not sure. Since JIRA is the main tool to manage and plan releases, let's link straight to it. That's also the place where users actually would file tickets (e.g. bugs or feature requests) -M > > > ----- Original Message ----- > From: "Daniel Bevenius" > To: "AeroGear Developer Mailing List" > Sent: Monday, December 15, 2014 11:08:31 AM > Subject: Re: [aerogear-dev] AeroGear.org - a first thought on changing our > roadmap docs > > > First step: replace existing roadmaps with links to JIRAs, where > possible. > > >Next step: re-think the entire roadmaps section. I am currently on that, > and it's not 100% yet clear, what's best. Once I have more on this, I will > share thoughts > Sounds good! > > On 15 December 2014 at 15:05, Matthias Wessendorf < matzew at apache.org > > wrote: > > > > Hey, > > that's what I am currently looking at - by doing the analysis of the site, > I noticed that our current roadmap docs just duplicate info from JIRA > > First step: replace existing roadmaps with links to JIRAs, where possible. > > Next step: re-think the entire roadmaps section. I am currently on that, > and it's not 100% yet clear, what's best. Once I have more on this, I will > share thoughts > > > > On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira < bruno at abstractj.org > > wrote: > > Alright, let's think about the following scenario. I'm a newcomer, going > aerogear.org to learn more about AeroGear and want to know what's planned > for the future > releases. Where should I look? > > On 2014-12-15, Matthias Wessendorf wrote: > > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira < bruno at abstractj.org > > wrote: > > > > > > Speaking from the security side of the things, to me is impossible to > > > have a feature driven roadmap, because it's a cross cutting concern. > > > > > > > right :-) > > > > looking at [1] I see different types of roadmaps > > > > 1) Project roadmap > > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) > > 3) cross cutting concerns (e.g. security) > > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) > > > > > > And that's fine :) For now, I'd really just like to get rid of the pages > > that basically duplicate info, available on JIRA :-) > > > > > > > > > > > > > > About removing the roadmap from website, as long as we make it clear > > > por people outside AeroGear, I'm fine. > > > > > > On 2014-12-15, Matthias Wessendorf wrote: > > > > Hi team, > > > > > > > > while thinking about restructuring our roadmaps, I was wondering > about > > > our > > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps > more > > > > feature driven, but that requires some more thoughts/changes? > > > > > > > > However, here is what I am wondering about... > > > > > > > > Most of our roadmaps we link to from [1], are really just pointing to > > > > different JIRAs. > > > > > > > > > > > > Let's take one example, UPS: > > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > > > Basically all info on the above page is present in JIRA (including > the > > > > 'archived' roadmap of older releases). Since JIRA should be the > central > > > > tool for planing releases, features and future versions, I think > that our > > > > roadmap docs are not adding too much value, since they repeat info > that > > > is > > > > available on a different place (JIRA). > > > > > > > > Also, maintaining the roadmaps is tedious: You make a change on the > > > actual > > > > JIRA (e.g. move the date of a release or add a new feature). To keep > the > > > > roadmap up-to-date, you put the same info on the roadmap doc and > send a > > > PR. > > > > > > > > > > > > Can we remove these roadmap docs? > > > > > > > > For UPS that would mean, that the link on [1] would go against: > > > > > > > > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel > > > > > > > > instead of here: > > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > > > -Matthias > > > > > > > > [1] https://aerogear.org/docs/planning/ > > > > > > > > > > > > -- > > > > 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 > > > _______________________________________________ > > 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141215/7181f7f6/attachment.html From cvasilak at gmail.com Mon Dec 15 10:08:49 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 15 Dec 2014 17:08:49 +0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Meeting ended Mon Dec 15 15:07:35 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-12-15-15.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-15-15.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-15-15.00.log.html On Sun, Dec 14, 2014 at 4:49 PM, Daniel Bevenius wrote: > > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20141215 > > _______________________________________________ > 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/20141215/7d9bdac1/attachment.html From matzew at apache.org Mon Dec 15 10:09:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 16:09:17 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: <20141215132555.GA88292@abstractj.org> <20141215134039.GA95353@abstractj.org> Message-ID: On Mon, Dec 15, 2014 at 3:21 PM, Matthias Wessendorf wrote: > > My current thought is, that on https://aerogear.org/docs/planning/ we > should not just have link. Straight on the page I'd like to list the next > planed features: > *OAuth2 > * Sync > *Offline > > Each item has a bit of details. > > and underneath these features, I'd like to place links to the JIRAs of the > different modules, like Security, Cordova etc. Basically like it is today > (with the little different of pointing to JIRA, instead of our own roadmap > docs, where possible). Let me PR this... > Not a PR, but a commit, to my branch: https://github.com/matzew/aerogear.org/commit/e6125d0e25203a37b69e09309898dc37f8dfaf2d > > > That is just a first step. more to come soon :) > > > > > > > On Mon, Dec 15, 2014 at 3:08 PM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: >> >> >First step: replace existing roadmaps with links to JIRAs, where >> possible. >> >> >Next step: re-think the entire roadmaps section. I am currently on that, >> and it's not 100% yet clear, what's best. Once I have more on this, I will >> share thoughts >> Sounds good! >> >> On 15 December 2014 at 15:05, Matthias Wessendorf >> wrote: >> >>> Hey, >>> >>> that's what I am currently looking at - by doing the analysis of the >>> site, I noticed that our current roadmap docs just duplicate info from JIRA >>> >>> First step: replace existing roadmaps with links to JIRAs, where >>> possible. >>> >>> Next step: re-think the entire roadmaps section. I am currently on that, >>> and it's not 100% yet clear, what's best. Once I have more on this, I will >>> share thoughts >>> >>> >>> >>> On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira >>> wrote: >>>> >>>> Alright, let's think about the following scenario. I'm a newcomer, going >>>> aerogear.org to learn more about AeroGear and want to know what's >>>> planned for the future >>>> releases. Where should I look? >>>> >>>> On 2014-12-15, Matthias Wessendorf wrote: >>>> > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira >>>> wrote: >>>> > > >>>> > > Speaking from the security side of the things, to me is impossible >>>> to >>>> > > have a feature driven roadmap, because it's a cross cutting concern. >>>> > > >>>> > >>>> > right :-) >>>> > >>>> > looking at [1] I see different types of roadmaps >>>> > >>>> > 1) Project roadmap >>>> > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) >>>> > 3) cross cutting concerns (e.g. security) >>>> > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) >>>> > >>>> > >>>> > And that's fine :) For now, I'd really just like to get rid of the >>>> pages >>>> > that basically duplicate info, available on JIRA :-) >>>> > >>>> > >>>> > >>>> > >>>> > > >>>> > > About removing the roadmap from website, as long as we make it clear >>>> > > por people outside AeroGear, I'm fine. >>>> > > >>>> > > On 2014-12-15, Matthias Wessendorf wrote: >>>> > > > Hi team, >>>> > > > >>>> > > > while thinking about restructuring our roadmaps, I was wondering >>>> about >>>> > > our >>>> > > > existing roadmaps on [1]. Overall I'd like to have the AG >>>> roadmaps more >>>> > > > feature driven, but that requires some more thoughts/changes? >>>> > > > >>>> > > > However, here is what I am wondering about... >>>> > > > >>>> > > > Most of our roadmaps we link to from [1], are really just >>>> pointing to >>>> > > > different JIRAs. >>>> > > > >>>> > > > >>>> > > > Let's take one example, UPS: >>>> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >>>> > > > >>>> > > > Basically all info on the above page is present in JIRA >>>> (including the >>>> > > > 'archived' roadmap of older releases). Since JIRA should be the >>>> central >>>> > > > tool for planing releases, features and future versions, I think >>>> that our >>>> > > > roadmap docs are not adding too much value, since they repeat >>>> info that >>>> > > is >>>> > > > available on a different place (JIRA). >>>> > > > >>>> > > > Also, maintaining the roadmaps is tedious: You make a change on >>>> the >>>> > > actual >>>> > > > JIRA (e.g. move the date of a release or add a new feature). To >>>> keep the >>>> > > > roadmap up-to-date, you put the same info on the roadmap doc and >>>> send a >>>> > > PR. >>>> > > > >>>> > > > >>>> > > > Can we remove these roadmap docs? >>>> > > > >>>> > > > For UPS that would mean, that the link on [1] would go against: >>>> > > > >>>> > > >>>> https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel >>>> > > > >>>> > > > instead of here: >>>> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >>>> > > > >>>> > > > -Matthias >>>> > > > >>>> > > > [1] https://aerogear.org/docs/planning/ >>>> > > > >>>> > > > >>>> > > > -- >>>> > > > 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 >>>> >>>> > _______________________________________________ >>>> > 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 > -- 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/20141215/9393ef15/attachment-0001.html From lholmqui at redhat.com Mon Dec 15 11:31:08 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 15 Dec 2014 11:31:08 -0500 Subject: [aerogear-dev] Concerns on JS Conflict Resolution lib Message-ID: <403DBD52-4F3A-4C83-BE38-00B775D63918@redhat.com> So i have some concerns on the Current state of the conflit resolution POC that i created. in it's current state, i had 3 methods in the api * Read - just a GET * Save - PUT/POST with an added "conflict" callback to handle the conflict resolution * Remove - just a DELETE This was all done before we wrote this spec https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/ but even then, from the JS client perspective, it felt a lot like a pipe. In jQuery.ajax, you can actually listen for a "409". The other thing that concerns me is that on the client side, people are using frameworks such as Ember, Angular, Backbone,etc... that have there own ways of doing server requests so i would hate to start re-inveting the wheel again. while the read/remove don't really do anything different(they are just GET/DELETE's), the save method(PUT/POST) does. This is were all the "conflict resolution happens?. (what type on resolution algorithm, auto-merge, etc...) I think it would be interesting to try to integrate this part into existing frameworks, rather than trying to create Pipeline again. i think for node.js this might be interesting too, since we could create a piece of middleware that hooks into an express/connect request Again, this might only be a concern on the JS client side, not sure what the other platforms are like in this regard From lukas.fryc at gmail.com Mon Dec 15 11:31:15 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 15 Dec 2014 17:31:15 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: <20141215132555.GA88292@abstractj.org> <20141215134039.GA95353@abstractj.org> <90466273.1130732.1418653076247.JavaMail.zimbra@redhat.com> Message-ID: +1 to having JIRA as single source of truth Eventually, we can really poll the JIRA REST API during the site build and populate the roadmap (together with linking to it). E.g. list all Epics associated with the given version on the built site, and link to the full roadmap. On Mon, Dec 15, 2014 at 3:23 PM, Matthias Wessendorf wrote: > > > > On Mon, Dec 15, 2014 at 3:17 PM, Andres Galante > wrote: >> >> Can't we have some kind of aggregator that reads the roadmaps from JIRA >> and print it on the website? >> > > Not sure. Since JIRA is the main tool to manage and plan releases, let's > link straight to it. That's also the place where users actually would file > tickets (e.g. bugs or feature requests) > > -M > > >> >> >> ----- Original Message ----- >> From: "Daniel Bevenius" >> To: "AeroGear Developer Mailing List" >> Sent: Monday, December 15, 2014 11:08:31 AM >> Subject: Re: [aerogear-dev] AeroGear.org - a first thought on changing >> our roadmap docs >> >> > First step: replace existing roadmaps with links to JIRAs, where >> possible. >> >> >Next step: re-think the entire roadmaps section. I am currently on that, >> and it's not 100% yet clear, what's best. Once I have more on this, I will >> share thoughts >> Sounds good! >> >> On 15 December 2014 at 15:05, Matthias Wessendorf < matzew at apache.org > >> wrote: >> >> >> >> Hey, >> >> that's what I am currently looking at - by doing the analysis of the >> site, I noticed that our current roadmap docs just duplicate info from JIRA >> >> First step: replace existing roadmaps with links to JIRAs, where possible. >> >> Next step: re-think the entire roadmaps section. I am currently on that, >> and it's not 100% yet clear, what's best. Once I have more on this, I will >> share thoughts >> >> >> >> On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira < bruno at abstractj.org > >> wrote: >> >> Alright, let's think about the following scenario. I'm a newcomer, going >> aerogear.org to learn more about AeroGear and want to know what's >> planned for the future >> releases. Where should I look? >> >> On 2014-12-15, Matthias Wessendorf wrote: >> > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira < bruno at abstractj.org >> > wrote: >> > > >> > > Speaking from the security side of the things, to me is impossible to >> > > have a feature driven roadmap, because it's a cross cutting concern. >> > > >> > >> > right :-) >> > >> > looking at [1] I see different types of roadmaps >> > >> > 1) Project roadmap >> > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) >> > 3) cross cutting concerns (e.g. security) >> > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) >> > >> > >> > And that's fine :) For now, I'd really just like to get rid of the pages >> > that basically duplicate info, available on JIRA :-) >> > >> > >> > >> > >> > > >> > > About removing the roadmap from website, as long as we make it clear >> > > por people outside AeroGear, I'm fine. >> > > >> > > On 2014-12-15, Matthias Wessendorf wrote: >> > > > Hi team, >> > > > >> > > > while thinking about restructuring our roadmaps, I was wondering >> about >> > > our >> > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps >> more >> > > > feature driven, but that requires some more thoughts/changes? >> > > > >> > > > However, here is what I am wondering about... >> > > > >> > > > Most of our roadmaps we link to from [1], are really just pointing >> to >> > > > different JIRAs. >> > > > >> > > > >> > > > Let's take one example, UPS: >> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >> > > > >> > > > Basically all info on the above page is present in JIRA (including >> the >> > > > 'archived' roadmap of older releases). Since JIRA should be the >> central >> > > > tool for planing releases, features and future versions, I think >> that our >> > > > roadmap docs are not adding too much value, since they repeat info >> that >> > > is >> > > > available on a different place (JIRA). >> > > > >> > > > Also, maintaining the roadmaps is tedious: You make a change on the >> > > actual >> > > > JIRA (e.g. move the date of a release or add a new feature). To >> keep the >> > > > roadmap up-to-date, you put the same info on the roadmap doc and >> send a >> > > PR. >> > > > >> > > > >> > > > Can we remove these roadmap docs? >> > > > >> > > > For UPS that would mean, that the link on [1] would go against: >> > > > >> > > >> https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel >> > > > >> > > > instead of here: >> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >> > > > >> > > > -Matthias >> > > > >> > > > [1] https://aerogear.org/docs/planning/ >> > > > >> > > > >> > > > -- >> > > > 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 >> >> > _______________________________________________ >> > 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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141215/66f880a3/attachment.html From matzew at apache.org Mon Dec 15 11:41:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 17:41:59 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: <20141215132555.GA88292@abstractj.org> <20141215134039.GA95353@abstractj.org> <90466273.1130732.1418653076247.JavaMail.zimbra@redhat.com> Message-ID: On Mon, Dec 15, 2014 at 5:31 PM, Luk?? Fry? wrote: > > +1 to having JIRA as single source of truth > > > Eventually, we can really poll the JIRA REST API during the site build and > populate the roadmap (together with linking to it). > > E.g. list all Epics associated with the given version on the built site, > and link to the full roadmap. > ok - that's an option, we could look into. > > > On Mon, Dec 15, 2014 at 3:23 PM, Matthias Wessendorf > wrote: >> >> >> >> On Mon, Dec 15, 2014 at 3:17 PM, Andres Galante >> wrote: >>> >>> Can't we have some kind of aggregator that reads the roadmaps from JIRA >>> and print it on the website? >>> >> >> Not sure. Since JIRA is the main tool to manage and plan releases, let's >> link straight to it. That's also the place where users actually would file >> tickets (e.g. bugs or feature requests) >> >> -M >> >> >>> >>> >>> ----- Original Message ----- >>> From: "Daniel Bevenius" >>> To: "AeroGear Developer Mailing List" >>> Sent: Monday, December 15, 2014 11:08:31 AM >>> Subject: Re: [aerogear-dev] AeroGear.org - a first thought on changing >>> our roadmap docs >>> >>> > First step: replace existing roadmaps with links to JIRAs, where >>> possible. >>> >>> >Next step: re-think the entire roadmaps section. I am currently on >>> that, and it's not 100% yet clear, what's best. Once I have more on this, I >>> will share thoughts >>> Sounds good! >>> >>> On 15 December 2014 at 15:05, Matthias Wessendorf < matzew at apache.org > >>> wrote: >>> >>> >>> >>> Hey, >>> >>> that's what I am currently looking at - by doing the analysis of the >>> site, I noticed that our current roadmap docs just duplicate info from JIRA >>> >>> First step: replace existing roadmaps with links to JIRAs, where >>> possible. >>> >>> Next step: re-think the entire roadmaps section. I am currently on that, >>> and it's not 100% yet clear, what's best. Once I have more on this, I will >>> share thoughts >>> >>> >>> >>> On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira < bruno at abstractj.org > >>> wrote: >>> >>> Alright, let's think about the following scenario. I'm a newcomer, going >>> aerogear.org to learn more about AeroGear and want to know what's >>> planned for the future >>> releases. Where should I look? >>> >>> On 2014-12-15, Matthias Wessendorf wrote: >>> > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira < bruno at abstractj.org >>> > wrote: >>> > > >>> > > Speaking from the security side of the things, to me is impossible to >>> > > have a feature driven roadmap, because it's a cross cutting concern. >>> > > >>> > >>> > right :-) >>> > >>> > looking at [1] I see different types of roadmaps >>> > >>> > 1) Project roadmap >>> > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) >>> > 3) cross cutting concerns (e.g. security) >>> > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) >>> > >>> > >>> > And that's fine :) For now, I'd really just like to get rid of the >>> pages >>> > that basically duplicate info, available on JIRA :-) >>> > >>> > >>> > >>> > >>> > > >>> > > About removing the roadmap from website, as long as we make it clear >>> > > por people outside AeroGear, I'm fine. >>> > > >>> > > On 2014-12-15, Matthias Wessendorf wrote: >>> > > > Hi team, >>> > > > >>> > > > while thinking about restructuring our roadmaps, I was wondering >>> about >>> > > our >>> > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps >>> more >>> > > > feature driven, but that requires some more thoughts/changes? >>> > > > >>> > > > However, here is what I am wondering about... >>> > > > >>> > > > Most of our roadmaps we link to from [1], are really just pointing >>> to >>> > > > different JIRAs. >>> > > > >>> > > > >>> > > > Let's take one example, UPS: >>> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >>> > > > >>> > > > Basically all info on the above page is present in JIRA (including >>> the >>> > > > 'archived' roadmap of older releases). Since JIRA should be the >>> central >>> > > > tool for planing releases, features and future versions, I think >>> that our >>> > > > roadmap docs are not adding too much value, since they repeat info >>> that >>> > > is >>> > > > available on a different place (JIRA). >>> > > > >>> > > > Also, maintaining the roadmaps is tedious: You make a change on the >>> > > actual >>> > > > JIRA (e.g. move the date of a release or add a new feature). To >>> keep the >>> > > > roadmap up-to-date, you put the same info on the roadmap doc and >>> send a >>> > > PR. >>> > > > >>> > > > >>> > > > Can we remove these roadmap docs? >>> > > > >>> > > > For UPS that would mean, that the link on [1] would go against: >>> > > > >>> > > >>> https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel >>> > > > >>> > > > instead of here: >>> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >>> > > > >>> > > > -Matthias >>> > > > >>> > > > [1] https://aerogear.org/docs/planning/ >>> > > > >>> > > > >>> > > > -- >>> > > > 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 >>> >>> > _______________________________________________ >>> > 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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.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/20141215/ad288a99/attachment-0001.html From bruno at abstractj.org Mon Dec 15 12:16:18 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Dec 2014 15:16:18 -0200 Subject: [aerogear-dev] User guide? Message-ID: <20141215171618.GA38140@abstractj.org> Good morning, while reviewing some docs I started to consider to build an AeroGear security user guide. At the same time I was wondering if instead worth to build an AeroGear user guide with security being one of the chapters. The goal is to centralize que information in a single document. Into this way people can read about it in ebook format or not. Does it worth the effort? -- abstractj PGP: 0x84DC9914 From matzew at apache.org Mon Dec 15 12:25:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 18:25:25 +0100 Subject: [aerogear-dev] User guide? In-Reply-To: <20141215171618.GA38140@abstractj.org> References: <20141215171618.GA38140@abstractj.org> Message-ID: not sure, if it does make sense. How about starting with a 'user guide' around our next big offerings around OAuth2, covering all our supported platforms and services? Does that make sense? On Mon, Dec 15, 2014 at 6:16 PM, Bruno Oliveira wrote: > > > Good morning, while reviewing some docs I started to consider to build > an AeroGear security user guide. At the same time I was wondering if > instead worth to build an AeroGear user guide with security being one of > the chapters. > > The goal is to centralize que information in a single document. Into > this way people can read about it in ebook format or not. > > Does it worth the effort? > > -- > > 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/20141215/6e4263f8/attachment.html From bruno at abstractj.org Mon Dec 15 12:56:03 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Dec 2014 15:56:03 -0200 Subject: [aerogear-dev] User guide? In-Reply-To: References: <20141215171618.GA38140@abstractj.org> Message-ID: <20141215175603.GB38140@abstractj.org> But that would be more like an AeroGear security user guide, no? Or I can just leave it as is. On 2014-12-15, Matthias Wessendorf wrote: > not sure, if it does make sense. > > How about starting with a 'user guide' around our next big offerings around > OAuth2, covering all our supported platforms and services? Does that make > sense? > > > > On Mon, Dec 15, 2014 at 6:16 PM, Bruno Oliveira wrote: > > > > > > Good morning, while reviewing some docs I started to consider to build > > an AeroGear security user guide. At the same time I was wondering if > > instead worth to build an AeroGear user guide with security being one of > > the chapters. > > > > The goal is to centralize que information in a single document. Into > > this way people can read about it in ebook format or not. > > > > Does it worth the effort? > > > > -- > > > > 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 scm.blanc at gmail.com Mon Dec 15 14:04:12 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Mon, 15 Dec 2014 20:04:12 +0100 Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: References: <20141215132555.GA88292@abstractj.org> <20141215134039.GA95353@abstractj.org> <90466273.1130732.1418653076247.JavaMail.zimbra@redhat.com> Message-ID: <3F023A03-AB42-4834-9ECE-D2D5753E5C2A@gmail.com> Envoy? de mon iPhone > Le 15 d?c. 2014 ? 17:41, Matthias Wessendorf a ?crit : > > > >> On Mon, Dec 15, 2014 at 5:31 PM, Luk?? Fry? wrote: >> +1 to having JIRA as single source of truth >> >> >> Eventually, we can really poll the JIRA REST API during the site build and populate the roadmap (together with linking to it). >> >> E.g. list all Epics associated with the given version on the built site, >> and link to the full roadmap. > > > ok - that's an option, we could look into. +1 to show the epics >> >> >>> On Mon, Dec 15, 2014 at 3:23 PM, Matthias Wessendorf wrote: >>> >>> >>>> On Mon, Dec 15, 2014 at 3:17 PM, Andres Galante wrote: >>>> Can't we have some kind of aggregator that reads the roadmaps from JIRA and print it on the website? >>> >>> Not sure. Since JIRA is the main tool to manage and plan releases, let's link straight to it. That's also the place where users actually would file tickets (e.g. bugs or feature requests) >>> >>> -M >>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Daniel Bevenius" >>>> To: "AeroGear Developer Mailing List" >>>> Sent: Monday, December 15, 2014 11:08:31 AM >>>> Subject: Re: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs >>>> >>>> > First step: replace existing roadmaps with links to JIRAs, where possible. >>>> >>>> >Next step: re-think the entire roadmaps section. I am currently on that, and it's not 100% yet clear, what's best. Once I have more on this, I will share thoughts >>>> Sounds good! >>>> >>>> On 15 December 2014 at 15:05, Matthias Wessendorf < matzew at apache.org > wrote: >>>> >>>> >>>> >>>> Hey, >>>> >>>> that's what I am currently looking at - by doing the analysis of the site, I noticed that our current roadmap docs just duplicate info from JIRA >>>> >>>> First step: replace existing roadmaps with links to JIRAs, where possible. >>>> >>>> Next step: re-think the entire roadmaps section. I am currently on that, and it's not 100% yet clear, what's best. Once I have more on this, I will share thoughts >>>> >>>> >>>> >>>> On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira < bruno at abstractj.org > wrote: >>>> >>>> Alright, let's think about the following scenario. I'm a newcomer, going >>>> aerogear.org to learn more about AeroGear and want to know what's planned for the future >>>> releases. Where should I look? >>>> >>>> On 2014-12-15, Matthias Wessendorf wrote: >>>> > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira < bruno at abstractj.org > wrote: >>>> > > >>>> > > Speaking from the security side of the things, to me is impossible to >>>> > > have a feature driven roadmap, because it's a cross cutting concern. >>>> > > >>>> > >>>> > right :-) >>>> > >>>> > looking at [1] I see different types of roadmaps >>>> > >>>> > 1) Project roadmap >>>> > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) >>>> > 3) cross cutting concerns (e.g. security) >>>> > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) >>>> > >>>> > >>>> > And that's fine :) For now, I'd really just like to get rid of the pages >>>> > that basically duplicate info, available on JIRA :-) >>>> > >>>> > >>>> > >>>> > >>>> > > >>>> > > About removing the roadmap from website, as long as we make it clear >>>> > > por people outside AeroGear, I'm fine. >>>> > > >>>> > > On 2014-12-15, Matthias Wessendorf wrote: >>>> > > > Hi team, >>>> > > > >>>> > > > while thinking about restructuring our roadmaps, I was wondering about >>>> > > our >>>> > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more >>>> > > > feature driven, but that requires some more thoughts/changes? >>>> > > > >>>> > > > However, here is what I am wondering about... >>>> > > > >>>> > > > Most of our roadmaps we link to from [1], are really just pointing to >>>> > > > different JIRAs. >>>> > > > >>>> > > > >>>> > > > Let's take one example, UPS: >>>> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >>>> > > > >>>> > > > Basically all info on the above page is present in JIRA (including the >>>> > > > 'archived' roadmap of older releases). Since JIRA should be the central >>>> > > > tool for planing releases, features and future versions, I think that our >>>> > > > roadmap docs are not adding too much value, since they repeat info that >>>> > > is >>>> > > > available on a different place (JIRA). >>>> > > > >>>> > > > Also, maintaining the roadmaps is tedious: You make a change on the >>>> > > actual >>>> > > > JIRA (e.g. move the date of a release or add a new feature). To keep the >>>> > > > roadmap up-to-date, you put the same info on the roadmap doc and send a >>>> > > PR. >>>> > > > >>>> > > > >>>> > > > Can we remove these roadmap docs? >>>> > > > >>>> > > > For UPS that would mean, that the link on [1] would go against: >>>> > > > >>>> > > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel >>>> > > > >>>> > > > instead of here: >>>> > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >>>> > > > >>>> > > > -Matthias >>>> > > > >>>> > > > [1] https://aerogear.org/docs/planning/ >>>> > > > >>>> > > > >>>> > > > -- >>>> > > > 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 >>>> >>>> > _______________________________________________ >>>> > 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 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.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/20141215/866ad5b5/attachment-0001.html From agalante at redhat.com Mon Dec 15 14:22:30 2014 From: agalante at redhat.com (Andres Galante) Date: Mon, 15 Dec 2014 14:22:30 -0500 (EST) Subject: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs In-Reply-To: <3F023A03-AB42-4834-9ECE-D2D5753E5C2A@gmail.com> References: <90466273.1130732.1418653076247.JavaMail.zimbra@redhat.com> <3F023A03-AB42-4834-9ECE-D2D5753E5C2A@gmail.com> Message-ID: <1961678578.1169094.1418671350236.JavaMail.zimbra@redhat.com> On the roadmap page there is a place to show the latest jira and github activity: http://andresgalante.com/aerogearwebsite/roadmap.html I'll adapt that to show a more extensive roadmap of epics ----- Original Message ----- From: "S?bastien Blanc" To: "AeroGear Developer Mailing List" Sent: Monday, December 15, 2014 4:04:12 PM Subject: Re: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs Envoy? de mon iPhone Le 15 d?c. 2014 ? 17:41, Matthias Wessendorf < matzew at apache.org > a ?crit : On Mon, Dec 15, 2014 at 5:31 PM, Luk?? Fry? < lukas.fryc at gmail.com > wrote: +1 to having JIRA as single source of truth Eventually, we can really poll the JIRA REST API during the site build and populate the roadmap (together with linking to it). E.g. list all Epics associated with the given version on the built site, and link to the full roadmap. ok - that's an option, we could look into. +1 to show the epics On Mon, Dec 15, 2014 at 3:23 PM, Matthias Wessendorf < matzew at apache.org > wrote: On Mon, Dec 15, 2014 at 3:17 PM, Andres Galante < agalante at redhat.com > wrote: Can't we have some kind of aggregator that reads the roadmaps from JIRA and print it on the website? Not sure. Since JIRA is the main tool to manage and plan releases, let's link straight to it. That's also the place where users actually would file tickets (e.g. bugs or feature requests) -M ----- Original Message ----- From: "Daniel Bevenius" < daniel.bevenius at gmail.com > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > Sent: Monday, December 15, 2014 11:08:31 AM Subject: Re: [aerogear-dev] AeroGear.org - a first thought on changing our roadmap docs > First step: replace existing roadmaps with links to JIRAs, where possible. >Next step: re-think the entire roadmaps section. I am currently on that, and it's not 100% yet clear, what's best. Once I have more on this, I will share thoughts Sounds good! On 15 December 2014 at 15:05, Matthias Wessendorf < matzew at apache.org > wrote: Hey, that's what I am currently looking at - by doing the analysis of the site, I noticed that our current roadmap docs just duplicate info from JIRA First step: replace existing roadmaps with links to JIRAs, where possible. Next step: re-think the entire roadmaps section. I am currently on that, and it's not 100% yet clear, what's best. Once I have more on this, I will share thoughts On Mon, Dec 15, 2014 at 2:40 PM, Bruno Oliveira < bruno at abstractj.org > wrote: Alright, let's think about the following scenario. I'm a newcomer, going aerogear.org to learn more about AeroGear and want to know what's planned for the future releases. Where should I look? On 2014-12-15, Matthias Wessendorf wrote: > On Mon, Dec 15, 2014 at 2:25 PM, Bruno Oliveira < bruno at abstractj.org > wrote: > > > > Speaking from the security side of the things, to me is impossible to > > have a feature driven roadmap, because it's a cross cutting concern. > > > > right :-) > > looking at [1] I see different types of roadmaps > > 1) Project roadmap > 2) Platform roadmaps (e.g. Android, Cordova, iOS and JS) > 3) cross cutting concerns (e.g. security) > 4) specific roadmaps (E.g. UPS/WebPush or even the WebSite roadmap) > > > And that's fine :) For now, I'd really just like to get rid of the pages > that basically duplicate info, available on JIRA :-) > > > > > > > > About removing the roadmap from website, as long as we make it clear > > por people outside AeroGear, I'm fine. > > > > On 2014-12-15, Matthias Wessendorf wrote: > > > Hi team, > > > > > > while thinking about restructuring our roadmaps, I was wondering about > > our > > > existing roadmaps on [1]. Overall I'd like to have the AG roadmaps more > > > feature driven, but that requires some more thoughts/changes? > > > > > > However, here is what I am wondering about... > > > > > > Most of our roadmaps we link to from [1], are really just pointing to > > > different JIRAs. > > > > > > > > > Let's take one example, UPS: > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > Basically all info on the above page is present in JIRA (including the > > > 'archived' roadmap of older releases). Since JIRA should be the central > > > tool for planing releases, features and future versions, I think that our > > > roadmap docs are not adding too much value, since they repeat info that > > is > > > available on a different place (JIRA). > > > > > > Also, maintaining the roadmaps is tedious: You make a change on the > > actual > > > JIRA (e.g. move the date of a release or add a new feature). To keep the > > > roadmap up-to-date, you put the same info on the roadmap doc and send a > > PR. > > > > > > > > > Can we remove these roadmap docs? > > > > > > For UPS that would mean, that the link on [1] would go against: > > > > > https://issues.jboss.org/browse/AGPUSH?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel > > > > > > instead of here: > > > https://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > -Matthias > > > > > > [1] https://aerogear.org/docs/planning/ > > > > > > > > > -- > > > 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 > _______________________________________________ > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 bruno at abstractj.org Mon Dec 15 15:08:55 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Dec 2014 18:08:55 -0200 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: Message-ID: <20141215200855.GA39465@abstractj.org> Good morning, first nice screencast Sebi and even knowing this is just a PoC I have some considerations: 1. What would be the use case scenario to justify a separated server instead of just a module on AGPUSH? 2. How do you plan to prevent people from faking their location? 3. Do we have a privacy policy to make the developer real aware about what's being collected? 4. Will collecting geo location be opt in or default? 5. Why is necessary to store current user's position? Couldn't admin specify a range and check how many devices are active on that region? Into this way you don't need to store their positions. I'm not the Geo specialist here but the idea is: 1. Admin specify the range when a push message must be sent. For example: Whole Florida 2. Client opt in and sent her its position to the server 3. Server compares and sent the push message I'm very concerned about privacy here, I'm not against the solution, but Geo location is like to open a Pandora box. We might be careful about unintentional disclosure of geolocation information, because it carries physical risks to the client (theft, to stalking, kidnapping and domestic violence ? I'm not exaggerating). Again, I know this is a proof of concept, but sooner we have it in mind, the better. On 2014-12-10, Sebastien Blanc wrote: > Hi all, > > I have been working on a POC around geolocation. Like we discussed in > another thread, we decided not to have a "deep" integration with the Push > server but instead a separate component / microservice. Well the POC is > more a miniservice ;) > > So, the idea is to have a server to which devices can register by providing > their positions. On the other side, the server provide an endpoint to make > spatial queries, like give me all the installations within a radius of 10 > km around this lat/ltg. > > Thanks to Forge, I created/scaffolded a really simple server providing the > registration endpoint and the search endpoint. > > I tried to make a decent readme that will give you more details : > > https://github.com/sebastienblanc/unified-geo-server > > And as usual, I made a little screencast showing all that in action ;) > > https://www.youtube.com/watch?v=R-qdLJh4EWQ > > Please remember this is a POC, so the security is almost inexistant, the > console is awful ;) > > What about the Client SDKs ? > > If we reach some kind of consensus arounf the concept of Unfied Geo Server > we can start building the Client SDKs / POCs , they will be quite simple : > retrieve geolocation and register to the geo endpoint. > > Sebi > _______________________________________________ > 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 Mon Dec 15 15:37:32 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 15 Dec 2014 21:37:32 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: <20141215200855.GA39465@abstractj.org> References: <20141215200855.GA39465@abstractj.org> Message-ID: On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira wrote: > > Good morning, first nice screencast Sebi and even knowing this is just a > PoC I have some considerations: > > 1. What would be the use case scenario to justify a separated server > instead of just a module on AGPUSH? > I think main discussion around this at F2F meeting was, it might be useful for other scenarios as well, and we don't want to hard-wire geo to the push server > > 2. How do you plan to prevent people from faking their location? > I'd assume that a Geo SDK would be based on-top of the mobile OS's facility, to receive the long/lat values. I think in the future we can have some sort of checks, like validating the users IP address, if it somewhat matches the submitted geo data. > > 3. Do we have a privacy policy to make the developer real aware about > what's being collected? > I think that the level of collected geo data is up to the developer of the app, using the Geo SDK. > > 4. Will collecting geo location be opt in or default? > If the Geo-data SDK is used w/in an app, I think it will still ask, up-front, if location based services are OK to use (at least apple). And I'd argue that users can still disable the geo usage, per app (at least apple) > > 5. Why is necessary to store current user's position? I think that's up to the use case, and its usage of the Geo SDK. > Couldn't admin > specify a range and check how many devices are active on that region? > Into this way you don't need to store their positions. I'm not the Geo > specialist here but the idea is: > > 1. Admin specify the range when a push message must be sent. For > example: Whole Florida > 2. Client opt in and sent her its position to the server > 3. Server compares and sent the push message > > I'm very concerned about privacy here, I'm not against the > solution, but Geo location is like to open a Pandora box. > yeah, it's also creepy :) I have not much services that I give my geo data > > We might be careful about unintentional disclosure of geolocation > information, > because it carries physical risks to the client (theft, to stalking, > kidnapping > and domestic violence ? I'm not exaggerating). > +1 I'd argue that the "Geo server" would be, initially, a 'simple' back end, that is able to store n pairs of long/lat values (grouped by a user/device). The mobile SDK for it basically store the 'collected' data to this backend (somewhat similar to the push registration SDK) > > Again, I know this is a proof of concept, but sooner we have it in mind, > the > better. > +1 fully agree. Replied to your questions with my POV on this > > > > > On 2014-12-10, Sebastien Blanc wrote: > > Hi all, > > > > I have been working on a POC around geolocation. Like we discussed in > > another thread, we decided not to have a "deep" integration with the Push > > server but instead a separate component / microservice. Well the POC is > > more a miniservice ;) > > > > So, the idea is to have a server to which devices can register by > providing > > their positions. On the other side, the server provide an endpoint to > make > > spatial queries, like give me all the installations within a radius of 10 > > km around this lat/ltg. > > > > Thanks to Forge, I created/scaffolded a really simple server providing > the > > registration endpoint and the search endpoint. > > > > I tried to make a decent readme that will give you more details : > > > > https://github.com/sebastienblanc/unified-geo-server > > > > And as usual, I made a little screencast showing all that in action ;) > > > > https://www.youtube.com/watch?v=R-qdLJh4EWQ > > > > Please remember this is a POC, so the security is almost inexistant, the > > console is awful ;) > > > > What about the Client SDKs ? > > > > If we reach some kind of consensus arounf the concept of Unfied Geo > Server > > we can start building the Client SDKs / POCs , they will be quite simple > : > > retrieve geolocation and register to the geo endpoint. > > > > Sebi > > > _______________________________________________ > > 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/20141215/3efc9bec/attachment-0001.html From scm.blanc at gmail.com Mon Dec 15 15:57:42 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Mon, 15 Dec 2014 21:57:42 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: <20141215200855.GA39465@abstractj.org> Message-ID: <45B63340-1A82-43B5-8E37-69B10F5CC6DC@gmail.com> Lots of things I was going to answer as already be done Matthias ;) But first of all thanks Bruno for this detailed answer. All your concerns make totally sense and it's by tackling them in the SDKs and the server that will make it a valuable piece of software that people would like to use. Some extra answers inline Envoy? de mon iPhone > Le 15 d?c. 2014 ? 21:37, Matthias Wessendorf a ?crit : > > > >> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira wrote: >> Good morning, first nice screencast Sebi and even knowing this is just a >> PoC I have some considerations: >> >> 1. What would be the use case scenario to justify a separated server >> instead of just a module on AGPUSH? > > I think main discussion around this at F2F meeting was, it might be useful for other scenarios as well, > and we don't want to hard-wire geo to the push server Yes, for instance all mobile apps would not need Push but would like use geo stuff. > > >> >> 2. How do you plan to prevent people from faking their location? > > I'd assume that a Geo SDK would be based on-top of the mobile OS's facility, to receive the long/lat values. > I think in the future we can have some sort of checks, like validating the users IP address, if it somewhat matches the submitted geo data. Yes adding this kind of security would really make the difference than a simple "send-my-location" library. Could keycloak for instance help to authenticate the SDK call ? Or token based stuff ? > > >> >> 3. Do we have a privacy policy to make the developer real aware about >> what's being collected? > > I think that the level of collected geo data is up to the developer of the app, using the Geo SDK. We could also add extra warnings in the documentation like Cordova does https://github.com/apache/cordova-plugin-geolocation/blob/master/doc/index.md > >> >> 4. Will collecting geo location be opt in or default? > > If the Geo-data SDK is used w/in an app, I think it will still ask, up-front, if location based services are OK to use (at least apple). And I'd argue that users can still disable the geo usage, per app (at least apple) > > > >> >> 5. Why is necessary to store current user's position? > > I think that's up to the use case, and its usage of the Geo SDK. > >> Couldn't admin >> specify a range and check how many devices are active on that region? >> Into this way you don't need to store their positions. I'm not the Geo >> specialist here but the idea is: >> >> 1. Admin specify the range when a push message must be sent. For >> example: Whole Florida >> 2. Client opt in and sent her its position to the server >> 3. Server compares and sent the push message >> >> I'm very concerned about privacy here, I'm not against the >> solution, but Geo location is like to open a Pandora box. > > yeah, it's also creepy :) I have not much services that I give my geo data > >> >> We might be careful about unintentional disclosure of geolocation information, >> because it carries physical risks to the client (theft, to stalking, kidnapping >> and domestic violence ? I'm not exaggerating). > > +1 I'd argue that the "Geo server" would be, initially, a 'simple' back end, that is able to store n pairs of long/lat values (grouped by a user/device). > The mobile SDK for it basically store the 'collected' data to this backend (somewhat similar to the push registration SDK) > >> >> Again, I know this is a proof of concept, but sooner we have it in mind, the >> better. > > +1 fully agree. Replied to your questions with my POV on this +1 as I said in the beginning of my message. > > >> >> >> >> >> On 2014-12-10, Sebastien Blanc wrote: >> > Hi all, >> > >> > I have been working on a POC around geolocation. Like we discussed in >> > another thread, we decided not to have a "deep" integration with the Push >> > server but instead a separate component / microservice. Well the POC is >> > more a miniservice ;) >> > >> > So, the idea is to have a server to which devices can register by providing >> > their positions. On the other side, the server provide an endpoint to make >> > spatial queries, like give me all the installations within a radius of 10 >> > km around this lat/ltg. >> > >> > Thanks to Forge, I created/scaffolded a really simple server providing the >> > registration endpoint and the search endpoint. >> > >> > I tried to make a decent readme that will give you more details : >> > >> > https://github.com/sebastienblanc/unified-geo-server >> > >> > And as usual, I made a little screencast showing all that in action ;) >> > >> > https://www.youtube.com/watch?v=R-qdLJh4EWQ >> > >> > Please remember this is a POC, so the security is almost inexistant, the >> > console is awful ;) >> > >> > What about the Client SDKs ? >> > >> > If we reach some kind of consensus arounf the concept of Unfied Geo Server >> > we can start building the Client SDKs / POCs , they will be quite simple : >> > retrieve geolocation and register to the geo endpoint. >> > >> > Sebi >> >> > _______________________________________________ >> > 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/20141215/e2efa1e7/attachment.html From bruno at abstractj.org Mon Dec 15 17:32:47 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Dec 2014 20:32:47 -0200 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: <20141215200855.GA39465@abstractj.org> Message-ID: <20141215223247.GA46696@abstractj.org> On 2014-12-15, Matthias Wessendorf wrote: > On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira wrote: > > > > Good morning, first nice screencast Sebi and even knowing this is just a > > PoC I have some considerations: > > > > 1. What would be the use case scenario to justify a separated server > > instead of just a module on AGPUSH? > > > > I think main discussion around this at F2F meeting was, it might be useful > for other scenarios as well, > and we don't want to hard-wire geo to the push server Which scenarios? > > > > > > > 2. How do you plan to prevent people from faking their location? > > > > I'd assume that a Geo SDK would be based on-top of the mobile OS's > facility, to receive the long/lat values. > I think in the future we can have some sort of checks, like validating the > users IP address, if it somewhat matches the submitted geo data. I think Geo based on IPs are a bad idea. This is a very inaccurate method and should be our last resort, it's easy to spoof IPs. > > > > > > > 3. Do we have a privacy policy to make the developer real aware about > > what's being collected? > > > > I think that the level of collected geo data is up to the developer of the > app, using the Geo SDK. I'm sorry, but I have to disagree. If we don't provide a policy about the usage of the Geo server, we're pretty much accountable for it. Nothing huge, only a simple txt documenting what's being collected and why. > > > > > > 4. Will collecting geo location be opt in or default? > > > > If the Geo-data SDK is used w/in an app, I think it will still ask, > up-front, if location based services are OK to use (at least apple). And > I'd argue that users can still disable the geo usage, per app (at least > apple) Most of users have no idea that their data is being collected. I'm confused about your answer, is that an yes or no? > > > > > > > > 5. Why is necessary to store current user's position? > > > I think that's up to the use case, and its usage of the Geo SDK. Currently we store. I know this is just a proof of concept. But I insist to be the boring, and avoid it if possible. > > > > Couldn't admin > > specify a range and check how many devices are active on that region? > > Into this way you don't need to store their positions. I'm not the Geo > > specialist here but the idea is: > > > > 1. Admin specify the range when a push message must be sent. For > > example: Whole Florida > > 2. Client opt in and sent her its position to the server > > 3. Server compares and sent the push message > > > > I'm very concerned about privacy here, I'm not against the > > solution, but Geo location is like to open a Pandora box. > > > > yeah, it's also creepy :) I have not much services that I give my geo data > > > > > > We might be careful about unintentional disclosure of geolocation > > information, > > because it carries physical risks to the client (theft, to stalking, > > kidnapping > > and domestic violence ? I'm not exaggerating). > > > > +1 I'd argue that the "Geo server" would be, initially, a 'simple' back > end, that is able to store n pairs of long/lat values (grouped by a > user/device). > The mobile SDK for it basically store the 'collected' data to this backend > (somewhat similar to the push registration SDK) > > > > > > Again, I know this is a proof of concept, but sooner we have it in mind, > > the > > better. > > > > +1 fully agree. Replied to your questions with my POV on this > > > > > > > > > > > > > On 2014-12-10, Sebastien Blanc wrote: > > > Hi all, > > > > > > I have been working on a POC around geolocation. Like we discussed in > > > another thread, we decided not to have a "deep" integration with the Push > > > server but instead a separate component / microservice. Well the POC is > > > more a miniservice ;) > > > > > > So, the idea is to have a server to which devices can register by > > providing > > > their positions. On the other side, the server provide an endpoint to > > make > > > spatial queries, like give me all the installations within a radius of 10 > > > km around this lat/ltg. > > > > > > Thanks to Forge, I created/scaffolded a really simple server providing > > the > > > registration endpoint and the search endpoint. > > > > > > I tried to make a decent readme that will give you more details : > > > > > > https://github.com/sebastienblanc/unified-geo-server > > > > > > And as usual, I made a little screencast showing all that in action ;) > > > > > > https://www.youtube.com/watch?v=R-qdLJh4EWQ > > > > > > Please remember this is a POC, so the security is almost inexistant, the > > > console is awful ;) > > > > > > What about the Client SDKs ? > > > > > > If we reach some kind of consensus arounf the concept of Unfied Geo > > Server > > > we can start building the Client SDKs / POCs , they will be quite simple > > : > > > retrieve geolocation and register to the geo endpoint. > > > > > > Sebi > > > > > _______________________________________________ > > > 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 -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Mon Dec 15 17:36:31 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Dec 2014 20:36:31 -0200 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: <45B63340-1A82-43B5-8E37-69B10F5CC6DC@gmail.com> References: <20141215200855.GA39465@abstractj.org> <45B63340-1A82-43B5-8E37-69B10F5CC6DC@gmail.com> Message-ID: <20141215223631.GB46696@abstractj.org> On 2014-12-15, S?bastien Blanc wrote: > Lots of things I was going to answer as already be done Matthias ;) > But first of all thanks Bruno for this detailed answer. > All your concerns make totally sense and it's by tackling them in the SDKs and the server that will make it a valuable piece of software that people would like to use. > Some extra answers inline > > Envoy? de mon iPhone > > > Le 15 d?c. 2014 ? 21:37, Matthias Wessendorf a ?crit : > > > > > > > >> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira wrote: > >> Good morning, first nice screencast Sebi and even knowing this is just a > >> PoC I have some considerations: > >> > >> 1. What would be the use case scenario to justify a separated server > >> instead of just a module on AGPUSH? > > > > I think main discussion around this at F2F meeting was, it might be useful for other scenarios as well, > > and we don't want to hard-wire geo to the push server > Yes, for instance all mobile apps would not need Push but would like use geo stuff. > > > > > >> > >> 2. How do you plan to prevent people from faking their location? > > > > I'd assume that a Geo SDK would be based on-top of the mobile OS's facility, to receive the long/lat values. > > I think in the future we can have some sort of checks, like validating the users IP address, if it somewhat matches the submitted geo data. > Yes adding this kind of security would really make the difference than a simple "send-my-location" library. > Could keycloak for instance help to authenticate the SDK call ? Or token based stuff ? Yes, it's possible to have some sorta of integration with Keycloak, but must be evaluated. > > > > > >> > >> 3. Do we have a privacy policy to make the developer real aware about > >> what's being collected? > > > > I think that the level of collected geo data is up to the developer of the app, using the Geo SDK. > We could also add extra warnings in the documentation like Cordova does https://github.com/apache/cordova-plugin-geolocation/blob/master/doc/index.md That makes sense, or https://www.google.com/privacy/lsf.html. > > > >> > >> 4. Will collecting geo location be opt in or default? > > > > If the Geo-data SDK is used w/in an app, I think it will still ask, up-front, if location based services are OK to use (at least apple). And I'd argue that users can still disable the geo usage, per app (at least apple) > > > > > > > >> > >> 5. Why is necessary to store current user's position? > > > > I think that's up to the use case, and its usage of the Geo SDK. > > > >> Couldn't admin > >> specify a range and check how many devices are active on that region? > >> Into this way you don't need to store their positions. I'm not the Geo > >> specialist here but the idea is: > >> > >> 1. Admin specify the range when a push message must be sent. For > >> example: Whole Florida > >> 2. Client opt in and sent her its position to the server > >> 3. Server compares and sent the push message > >> > >> I'm very concerned about privacy here, I'm not against the > >> solution, but Geo location is like to open a Pandora box. > > > > yeah, it's also creepy :) I have not much services that I give my geo data > > > >> > >> We might be careful about unintentional disclosure of geolocation information, > >> because it carries physical risks to the client (theft, to stalking, kidnapping > >> and domestic violence ? I'm not exaggerating). > > > > +1 I'd argue that the "Geo server" would be, initially, a 'simple' back end, that is able to store n pairs of long/lat values (grouped by a user/device). > > The mobile SDK for it basically store the 'collected' data to this backend (somewhat similar to the push registration SDK) > > > >> > >> Again, I know this is a proof of concept, but sooner we have it in mind, the > >> better. > > > > +1 fully agree. Replied to your questions with my POV on this > +1 as I said in the beginning of my message. > > > > > >> > >> > >> > >> > >> On 2014-12-10, Sebastien Blanc wrote: > >> > Hi all, > >> > > >> > I have been working on a POC around geolocation. Like we discussed in > >> > another thread, we decided not to have a "deep" integration with the Push > >> > server but instead a separate component / microservice. Well the POC is > >> > more a miniservice ;) > >> > > >> > So, the idea is to have a server to which devices can register by providing > >> > their positions. On the other side, the server provide an endpoint to make > >> > spatial queries, like give me all the installations within a radius of 10 > >> > km around this lat/ltg. > >> > > >> > Thanks to Forge, I created/scaffolded a really simple server providing the > >> > registration endpoint and the search endpoint. > >> > > >> > I tried to make a decent readme that will give you more details : > >> > > >> > https://github.com/sebastienblanc/unified-geo-server > >> > > >> > And as usual, I made a little screencast showing all that in action ;) > >> > > >> > https://www.youtube.com/watch?v=R-qdLJh4EWQ > >> > > >> > Please remember this is a POC, so the security is almost inexistant, the > >> > console is awful ;) > >> > > >> > What about the Client SDKs ? > >> > > >> > If we reach some kind of consensus arounf the concept of Unfied Geo Server > >> > we can start building the Client SDKs / POCs , they will be quite simple : > >> > retrieve geolocation and register to the geo endpoint. > >> > > >> > Sebi > >> > >> > _______________________________________________ > >> > 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 -- abstractj PGP: 0x84DC9914 From scm.blanc at gmail.com Mon Dec 15 18:10:10 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 16 Dec 2014 00:10:10 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: <20141215223247.GA46696@abstractj.org> References: <20141215200855.GA39465@abstractj.org> <20141215223247.GA46696@abstractj.org> Message-ID: On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira wrote: > > On 2014-12-15, Matthias Wessendorf wrote: > > On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira > wrote: > > > > > > Good morning, first nice screencast Sebi and even knowing this is just > a > > > PoC I have some considerations: > > > > > > 1. What would be the use case scenario to justify a separated server > > > instead of just a module on AGPUSH? > > > > > > > I think main discussion around this at F2F meeting was, it might be > useful > > for other scenarios as well, > > and we don't want to hard-wire geo to the push server > > Which scenarios? > The are several scenarios where geo is needed without push. For instance, think of a backend system for a transport company that needs to run analysis each night based on the current location of the truck drivers in order to plan efficiently the logistics for the next day. > > > > > > > > > > > > > 2. How do you plan to prevent people from faking their location? > > > > > > > I'd assume that a Geo SDK would be based on-top of the mobile OS's > > facility, to receive the long/lat values. > > I think in the future we can have some sort of checks, like validating > the > > users IP address, if it somewhat matches the submitted geo data. > > I think Geo based on IPs are a bad idea. This is a very inaccurate method > and should be our last resort, it's easy to spoof IPs. > > > > > > > > > > > > > 3. Do we have a privacy policy to make the developer real aware about > > > what's being collected? > > > > > > > I think that the level of collected geo data is up to the developer of > the > > app, using the Geo SDK. > > I'm sorry, but I have to disagree. If we don't provide a policy about the > usage of the Geo > server, we're pretty much accountable for it. > > Nothing huge, only a simple txt documenting what's being collected and > why. > > > > > > > > > > > 4. Will collecting geo location be opt in or default? > > > > > > > If the Geo-data SDK is used w/in an app, I think it will still ask, > > up-front, if location based services are OK to use (at least apple). And > > I'd argue that users can still disable the geo usage, per app (at least > > apple) > > Most of users have no idea that their data is being collected. I'm > confused about your answer, is that an yes or no? > I think what Matthias means is that when using gelolocation on the device, being iOS, Android or even Web, the users will be prompted to allow or not access to his geodata. So, yes it's an opt-in and also, like Matthias said a the possibility to opt-out. > > > > > > > > > > > > > > > 5. Why is necessary to store current user's position? > > > > > > I think that's up to the use case, and its usage of the Geo SDK. > > Currently we store. I know this is just a proof of concept. > But I insist to be the boring, and avoid it if possible. > If we don't store we can not make geo queries. Without these queries the question of having a geo server is quite useless ... But we could think of a "flavor" or variant ;) where the geo data is not persisted but just pass through (to a queue, another REST endpoint), It will more act then like a broker, but again not sure if I can find a usecase for that. > > > > > > > > > Couldn't admin > > > specify a range and check how many devices are active on that region? > > > Into this way you don't need to store their positions. I'm not the Geo > > > specialist here but the idea is: > > > > > > 1. Admin specify the range when a push message must be sent. For > > > example: Whole Florida > > > 2. Client opt in and sent her its position to the server > > > 3. Server compares and sent the push message > > > > > > I'm very concerned about privacy here, I'm not against the > > > solution, but Geo location is like to open a Pandora box. > > > > > > > yeah, it's also creepy :) I have not much services that I give my geo > data > > > > > > > > > > We might be careful about unintentional disclosure of geolocation > > > information, > > > because it carries physical risks to the client (theft, to stalking, > > > kidnapping > > > and domestic violence ? I'm not exaggerating). > > > > > > > +1 I'd argue that the "Geo server" would be, initially, a 'simple' back > > end, that is able to store n pairs of long/lat values (grouped by a > > user/device). > > The mobile SDK for it basically store the 'collected' data to this > backend > > (somewhat similar to the push registration SDK) > > > > > > > > > > Again, I know this is a proof of concept, but sooner we have it in > mind, > > > the > > > better. > > > > > > > +1 fully agree. Replied to your questions with my POV on this > > > > > > > > > > > > > > > > > > > > > On 2014-12-10, Sebastien Blanc wrote: > > > > Hi all, > > > > > > > > I have been working on a POC around geolocation. Like we discussed in > > > > another thread, we decided not to have a "deep" integration with the > Push > > > > server but instead a separate component / microservice. Well the POC > is > > > > more a miniservice ;) > > > > > > > > So, the idea is to have a server to which devices can register by > > > providing > > > > their positions. On the other side, the server provide an endpoint to > > > make > > > > spatial queries, like give me all the installations within a radius > of 10 > > > > km around this lat/ltg. > > > > > > > > Thanks to Forge, I created/scaffolded a really simple server > providing > > > the > > > > registration endpoint and the search endpoint. > > > > > > > > I tried to make a decent readme that will give you more details : > > > > > > > > https://github.com/sebastienblanc/unified-geo-server > > > > > > > > And as usual, I made a little screencast showing all that in action > ;) > > > > > > > > https://www.youtube.com/watch?v=R-qdLJh4EWQ > > > > > > > > Please remember this is a POC, so the security is almost inexistant, > the > > > > console is awful ;) > > > > > > > > What about the Client SDKs ? > > > > > > > > If we reach some kind of consensus arounf the concept of Unfied Geo > > > Server > > > > we can start building the Client SDKs / POCs , they will be quite > simple > > > : > > > > retrieve geolocation and register to the geo endpoint. > > > > > > > > Sebi > > > > > > > _______________________________________________ > > > > 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 > > > -- > > 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/20141216/6ca3ccf2/attachment.html From matzew at apache.org Tue Dec 16 00:13:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 16 Dec 2014 06:13:59 +0100 Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: <20141215223247.GA46696@abstractj.org> References: <20141215200855.GA39465@abstractj.org> <20141215223247.GA46696@abstractj.org> Message-ID: On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira wrote: > > On 2014-12-15, Matthias Wessendorf wrote: > > On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira > wrote: > > > > > > Good morning, first nice screencast Sebi and even knowing this is just > a > > > PoC I have some considerations: > > > > > > 1. What would be the use case scenario to justify a separated server > > > instead of just a module on AGPUSH? > > > > > > > I think main discussion around this at F2F meeting was, it might be > useful > > for other scenarios as well, > > and we don't want to hard-wire geo to the push server > > Which scenarios? > anything else that may require geo data. E.g. other systems may benefit from interacting with geo as well. I really do not see a reason why geo is hard-wired to push. the geo server should be a system to store any sorts of geo data (long/lat) + some APIs to query. > > > > > > > > > > > > > 2. How do you plan to prevent people from faking their location? > > > > > > > I'd assume that a Geo SDK would be based on-top of the mobile OS's > > facility, to receive the long/lat values. > > I think in the future we can have some sort of checks, like validating > the > > users IP address, if it somewhat matches the submitted geo data. > > I think Geo based on IPs are a bad idea. This is a very inaccurate method > and should be our last resort, it's easy to spoof IPs. > :-) yeah. I'd assume that we offer minimal/simple SDKs for iOS/Android, which underneath leverage the OS facilities for Geo-Data. Like CoreLocation on iOS. Regarding the IP, I had this in mind (not sure if that is a good idea or not): * if long/lat (can be faked with man-in-the-middle) says Germany, but IP says singapore, our server could see: something is wrong. or if we get weird long/lats from the same device (.e.g. 12:00 Germany, 12:30 UK, 14:00 USA, 14:30 China), we might know something is wrong too. But that's perhaps not for the initial scope of the poc > > > > > > > > > > > > 3. Do we have a privacy policy to make the developer real aware about > > > what's being collected? > > > > > > > I think that the level of collected geo data is up to the developer of > the > > app, using the Geo SDK. > > I'm sorry, but I have to disagree. If we don't provide a policy about the > usage of the Geo > server, we're pretty much accountable for it. > > Nothing huge, only a simple txt documenting what's being collected and > why. > I'd think that, if we provide an SDK (and the POC will get us there), we do not really track anything 'silently'. I hope that the SDK would allow me to get the current position (e.g. using CoreLocation), and store it with a name (e.g. home, work, my fav. cinema) and some metadata (e.g. username). But I'd not imagine our SDK constantly tracks all positions and silently sends them to the Geo Server. > > > > > > > > > > > 4. Will collecting geo location be opt in or default? > > > > > > > If the Geo-data SDK is used w/in an app, I think it will still ask, > > up-front, if location based services are OK to use (at least apple). And > > I'd argue that users can still disable the geo usage, per app (at least > > apple) > > Most of users have no idea that their data is being collected. I'm > confused about your answer, is that an yes or no? > I mean yes, see above. -MAtthias > > > > > > > > > > > > > > 5. Why is necessary to store current user's position? > > > > > > I think that's up to the use case, and its usage of the Geo SDK. > > Currently we store. I know this is just a proof of concept. > But I insist to be the boring, and avoid it if possible. > > > > > > > > > Couldn't admin > > > specify a range and check how many devices are active on that region? > > > Into this way you don't need to store their positions. I'm not the Geo > > > specialist here but the idea is: > > > > > > 1. Admin specify the range when a push message must be sent. For > > > example: Whole Florida > > > 2. Client opt in and sent her its position to the server > > > 3. Server compares and sent the push message > > > > > > I'm very concerned about privacy here, I'm not against the > > > solution, but Geo location is like to open a Pandora box. > > > > > > > yeah, it's also creepy :) I have not much services that I give my geo > data > > > > > > > > > > We might be careful about unintentional disclosure of geolocation > > > information, > > > because it carries physical risks to the client (theft, to stalking, > > > kidnapping > > > and domestic violence ? I'm not exaggerating). > > > > > > > +1 I'd argue that the "Geo server" would be, initially, a 'simple' back > > end, that is able to store n pairs of long/lat values (grouped by a > > user/device). > > The mobile SDK for it basically store the 'collected' data to this > backend > > (somewhat similar to the push registration SDK) > > > > > > > > > > Again, I know this is a proof of concept, but sooner we have it in > mind, > > > the > > > better. > > > > > > > +1 fully agree. Replied to your questions with my POV on this > > > > > > > > > > > > > > > > > > > > > On 2014-12-10, Sebastien Blanc wrote: > > > > Hi all, > > > > > > > > I have been working on a POC around geolocation. Like we discussed in > > > > another thread, we decided not to have a "deep" integration with the > Push > > > > server but instead a separate component / microservice. Well the POC > is > > > > more a miniservice ;) > > > > > > > > So, the idea is to have a server to which devices can register by > > > providing > > > > their positions. On the other side, the server provide an endpoint to > > > make > > > > spatial queries, like give me all the installations within a radius > of 10 > > > > km around this lat/ltg. > > > > > > > > Thanks to Forge, I created/scaffolded a really simple server > providing > > > the > > > > registration endpoint and the search endpoint. > > > > > > > > I tried to make a decent readme that will give you more details : > > > > > > > > https://github.com/sebastienblanc/unified-geo-server > > > > > > > > And as usual, I made a little screencast showing all that in action > ;) > > > > > > > > https://www.youtube.com/watch?v=R-qdLJh4EWQ > > > > > > > > Please remember this is a POC, so the security is almost inexistant, > the > > > > console is awful ;) > > > > > > > > What about the Client SDKs ? > > > > > > > > If we reach some kind of consensus arounf the concept of Unfied Geo > > > Server > > > > we can start building the Client SDKs / POCs , they will be quite > simple > > > : > > > > retrieve geolocation and register to the geo endpoint. > > > > > > > > Sebi > > > > > > > _______________________________________________ > > > > 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 > > > -- > > 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/20141216/4a03ce13/attachment-0001.html From cvasilak at gmail.com Tue Dec 16 01:36:10 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 16 Dec 2014 08:36:10 +0200 Subject: [aerogear-dev] Pre-release announcement of iOS libraries Message-ID: Hi AeroGear community, we are happy to announce a pre-release of our various iOS libraries. Here are few of new features introduced in each respective list: - aerogear-ios-jsonsz (new) A newly introduced library which will take care the cumbersome plumbing required when performing JSON serialisation back and forth from your Swift object model. For an example usage of the library together with our http-lib check our Buddies cookbook example. - aerogear-ios-http We added the ability to perform basic/digest authentication when performing REST Requests. Check out our Authentication cookbook example, for an example usage of the API but remember to prefer HTTPS over plain HTTP when performing authentication of this type. - aerogear-ios-oauth2 Continuing the development of our OAuth2 library, OpenID Connect support was added to the library in the form of a ?login? request. Checkout out our ?SharedShoot? cookbook example that login's to KeyCloak using OpenID connect for an example usage. - aerogear-ios-httpstub Stubbed responses from the local file system can be used instead of coding them in your code. This will make easier to stub responses, especially big ones and be much ?closer? to the reality. Check out our tests for an example usage. Last, this release introduces Cocoapod support for our libraries. Although Cocoapods hasn?t yet officially support ?Swift? that is planned for the next 0.36 release, a branch on the project is working on it and already libraries starting to adopt. Just make sure to include a Gemfile in your project pointing to that cocoapods branch (see here for more detailed instructions) and in your Podfile include the desired library. For example usage, see our cookbook repository where all of our demos have been converted. So, give the libraries and demos a spin and let us know what you think. If no bad things heard we are planning to tag and officially release 2.1 this Friday. Have fun! Corinne & Christos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141216/e39a9650/attachment.html From matzew at apache.org Tue Dec 16 01:43:11 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 16 Dec 2014 07:43:11 +0100 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: References: Message-ID: sounds good! do you want to publish this (after the release) on the aerogear.org site ? Sounds like a nice summary/post to me On Tue, Dec 16, 2014 at 7:36 AM, Christos Vasilakis wrote: > > Hi AeroGear community, > > we are happy to announce a pre-release of our various iOS libraries. Here > are few of new features introduced in each respective list: > > - aerogear-ios-jsonsz > (new) > A newly introduced library which will take care the cumbersome plumbing > required when performing JSON serialisation back and forth from your Swift > object model. For an example usage of the library together with our > http-lib check our Buddies cookbook example > . > - aerogear-ios-http > We added the ability to perform basic/digest authentication when > performing REST Requests. Check out our Authentication cookbook example > , > for an example usage of the API but remember to prefer HTTPS over plain > HTTP when performing authentication of this type. > > - aerogear-ios-oauth2 > Continuing the development of our OAuth2 library, OpenID Connect support > was added to the library in the form of a ?login? request. Checkout out our ?SharedShoot? > cookbook example > that > login's to KeyCloak using OpenID connect for > an example usage. > > - aerogear-ios-httpstub > > Stubbed responses from the local file system can be used instead of coding > them in your code. This will make easier to stub responses, especially big > ones and be much ?closer? to the reality. Check out our tests > for > an example usage. > > > Last, this release introduces Cocoapod support for > our libraries. Although Cocoapods hasn?t yet officially support ?Swift? > that is planned for the next 0.36 release, a branch > on the project is > working on it and already libraries starting to adopt. Just make sure to > include a Gemfile in your project pointing to that cocoapods branch (see > here for more > detailed instructions) and in your Podfile include the desired library. For > example usage, see our cookbook repository > where all of our > demos have been converted. > > So, give the libraries and demos a spin and let us know what you think. > If no bad things heard we are planning to tag and officially release 2.1 > this Friday. > > Have fun! > > Corinne & Christos > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141216/257f186b/attachment.html From cvasilak at gmail.com Tue Dec 16 01:46:29 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 16 Dec 2014 08:46:29 +0200 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: References: Message-ID: <4FD31E64-844C-4279-92CF-7493C607DB53@gmail.com> On Dec 16, 2014, at 8:43 AM, Matthias Wessendorf wrote: > sounds good! > > do you want to publish this (after the release) on the aerogear.org site ? Sounds like a nice summary/post to me absolutely +1 - Christos > > -- > 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/20141216/a9714bbc/attachment.html From daniel.bevenius at gmail.com Tue Dec 16 01:59:32 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 16 Dec 2014 07:59:32 +0100 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: <4FD31E64-844C-4279-92CF-7493C607DB53@gmail.com> References: <4FD31E64-844C-4279-92CF-7493C607DB53@gmail.com> Message-ID: Very nice, great work! tisdag 16 december 2014 skrev Christos Vasilakis : > > On Dec 16, 2014, at 8:43 AM, Matthias Wessendorf > wrote: > > sounds good! > > do you want to publish this (after the release) on the aerogear.org site > ? Sounds like a nice summary/post to me > > > absolutely +1 > > - > Christos > > > > -- > 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/20141216/39f4eea0/attachment.html From lukas.fryc at gmail.com Tue Dec 16 04:22:39 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Tue, 16 Dec 2014 10:22:39 +0100 Subject: [aerogear-dev] Concerns on JS Conflict Resolution lib In-Reply-To: <403DBD52-4F3A-4C83-BE38-00B775D63918@redhat.com> References: <403DBD52-4F3A-4C83-BE38-00B775D63918@redhat.com> Message-ID: Hey Luke, That seems sensible. I'm glad you are questioning this at the very beginning. JS conflict resolution in my eyes makes sense if we build some kind of ORM or three-way binding solution (we'd obviously create just client-model-to-server-model binding part, the rest is up to the MVC framework). I also believe that Conflict Resolution API shouldn't be much different from our Realtime sync from the API standpoint, the real difference is that Conflict Resolution can easily intergrate with existing concepts and backends because of its RESTful nature, while Realtime sync requires special backend handling (aka sync-server): Sync.save(objectInstance); Additionally, Conflict Resolution has points on the roadmap that goes far behind regular framework principles: Partial Updates, Batch Updates, Server Notifications... As discussed on F2F, we should though always think about how this integrates into wider picture (existing frameworks). For this moment, we could start just with examples, they could also demonstrate us what deficiencies existing solutions have. And if nothing, the only deliverable for conflict resolution at the end maybe a cookbook, a doc/guide and maybe some contributions to upstream :-) On Mon, Dec 15, 2014 at 5:31 PM, Lucas Holmquist wrote: > > So i have some concerns on the Current state of the conflit resolution POC > that i created. > > in it's current state, i had 3 methods in the api > > * Read - just a GET > * Save - PUT/POST with an added "conflict" callback to handle the conflict > resolution > * Remove - just a DELETE > > This was all done before we wrote this spec > > https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/ > > but even then, from the JS client perspective, it felt a lot like a > pipe. In jQuery.ajax, you can actually listen for a "409". > > The other thing that concerns me is that on the client side, people are > using frameworks such as Ember, Angular, Backbone,etc... that have there > own ways of doing server requests so i would hate to start re-inveting the > wheel again. > > while the read/remove don't really do anything different(they are just > GET/DELETE's), the save method(PUT/POST) does. This is were all the > "conflict resolution happens?. (what type on resolution algorithm, > auto-merge, etc...) > > I think it would be interesting to try to integrate this part into > existing frameworks, rather than trying to create Pipeline again. > > i think for node.js this might be interesting too, since we could create a > piece of middleware that hooks into an express/connect request > > > Again, this might only be a concern on the JS client side, not sure what > the other platforms are like in this regard > > > _______________________________________________ > 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/20141216/f72f2906/attachment-0001.html From matzew at apache.org Tue Dec 16 06:41:41 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 16 Dec 2014 12:41:41 +0100 Subject: [aerogear-dev] Concerns on JS Conflict Resolution lib In-Reply-To: <403DBD52-4F3A-4C83-BE38-00B775D63918@redhat.com> References: <403DBD52-4F3A-4C83-BE38-00B775D63918@redhat.com> Message-ID: my understand was that the main focus is now on the real-time sync, leveraging out differential synchronization engine. This reflects also the current move of removing the 'rest sync' module https://github.com/aerogear/aerogear-sync-server/commit/5fe0b240d646ef57c5927f726c6bf2c04aa5d3cc -Matthias On Mon, Dec 15, 2014 at 5:31 PM, Lucas Holmquist wrote: > > So i have some concerns on the Current state of the conflit resolution POC > that i created. > > in it's current state, i had 3 methods in the api > > * Read - just a GET > * Save - PUT/POST with an added "conflict" callback to handle the conflict > resolution > * Remove - just a DELETE > > This was all done before we wrote this spec > > https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/ > > but even then, from the JS client perspective, it felt a lot like a > pipe. In jQuery.ajax, you can actually listen for a "409". > > The other thing that concerns me is that on the client side, people are > using frameworks such as Ember, Angular, Backbone,etc... that have there > own ways of doing server requests so i would hate to start re-inveting the > wheel again. > > while the read/remove don't really do anything different(they are just > GET/DELETE's), the save method(PUT/POST) does. This is were all the > "conflict resolution happens?. (what type on resolution algorithm, > auto-merge, etc...) > > I think it would be interesting to try to integrate this part into > existing frameworks, rather than trying to create Pipeline again. > > i think for node.js this might be interesting too, since we could create a > piece of middleware that hooks into an express/connect request > > > Again, this might only be a concern on the JS client side, not sure what > the other platforms are like in this regard > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141216/86b4df42/attachment.html From lholmqui at redhat.com Tue Dec 16 08:35:43 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 16 Dec 2014 08:35:43 -0500 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: References: Message-ID: <4CCBDDA6-CE6D-4FDA-A73F-17BAE86FC51D@redhat.com> this is pretty rad!! i like how ?swiftly? these releases are coming out. :) > On Dec 16, 2014, at 1:36 AM, Christos Vasilakis wrote: > > Hi AeroGear community, > > we are happy to announce a pre-release of our various iOS libraries. Here are few of new features introduced in each respective list: > > - aerogear-ios-jsonsz (new) > A newly introduced library which will take care the cumbersome plumbing required when performing JSON serialisation back and forth from your Swift object model. For an example usage of the library together with our http-lib check our Buddies cookbook example . > > - aerogear-ios-http > We added the ability to perform basic/digest authentication when performing REST Requests. Check out our Authentication cookbook example , for an example usage of the API but remember to prefer HTTPS over plain HTTP when performing authentication of this type. > > - aerogear-ios-oauth2 > Continuing the development of our OAuth2 library, OpenID Connect support was added to the library in the form of a ?login? request. Checkout out our ?SharedShoot? cookbook example that login's to KeyCloak using OpenID connect for an example usage. > > - aerogear-ios-httpstub > Stubbed responses from the local file system can be used instead of coding them in your code. This will make easier to stub responses, especially big ones and be much ?closer? to the reality. Check out our tests? for an example usage. > > > Last, this release introduces Cocoapod support for our libraries. Although Cocoapods hasn?t yet officially support ?Swift? that is planned for the next 0.36 release, a branch on the project is working on it and already libraries starting to adopt. Just make sure to include a Gemfile in your project pointing to that cocoapods branch (see here for more detailed instructions) and in your Podfile include the desired library. For example usage, see our cookbook repository where all of our demos have been converted. > > So, give the libraries and demos a spin and let us know what you think. If no bad things heard we are planning to tag and officially release 2.1 this Friday. > > Have fun! > > Corinne & Christos > > > > _______________________________________________ > 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/20141216/a6e26056/attachment.html From lholmqui at redhat.com Tue Dec 16 08:39:26 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 16 Dec 2014 08:39:26 -0500 Subject: [aerogear-dev] Concerns on JS Conflict Resolution lib In-Reply-To: References: <403DBD52-4F3A-4C83-BE38-00B775D63918@redhat.com> Message-ID: > On Dec 16, 2014, at 6:41 AM, Matthias Wessendorf wrote: > > my understand was that the main focus is now on the real-time sync, leveraging out differential synchronization engine. i was not aware of that. I was under the understanding that both would be done in parallel since conflict resolution might be the solution for many people > > This reflects also the current move of removing the 'rest sync' module > https://github.com/aerogear/aerogear-sync-server/commit/5fe0b240d646ef57c5927f726c6bf2c04aa5d3cc > > -Matthias > > On Mon, Dec 15, 2014 at 5:31 PM, Lucas Holmquist > wrote: > So i have some concerns on the Current state of the conflit resolution POC that i created. > > in it's current state, i had 3 methods in the api > > * Read - just a GET > * Save - PUT/POST with an added "conflict" callback to handle the conflict resolution > * Remove - just a DELETE > > This was all done before we wrote this spec > > https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/ > > but even then, from the JS client perspective, it felt a lot like a pipe. In jQuery.ajax, you can actually listen for a "409". > > The other thing that concerns me is that on the client side, people are using frameworks such as Ember, Angular, Backbone,etc... that have there own ways of doing server requests so i would hate to start re-inveting the wheel again. > > while the read/remove don't really do anything different(they are just GET/DELETE's), the save method(PUT/POST) does. This is were all the "conflict resolution happens?. (what type on resolution algorithm, auto-merge, etc...) > > I think it would be interesting to try to integrate this part into existing frameworks, rather than trying to create Pipeline again. > > i think for node.js this might be interesting too, since we could create a piece of middleware that hooks into an express/connect request > > > Again, this might only be a concern on the JS client side, not sure what the other platforms are like in this regard > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141216/4bb19a6c/attachment.html From lholmqui at redhat.com Tue Dec 16 08:42:40 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 16 Dec 2014 08:42:40 -0500 Subject: [aerogear-dev] Concerns on JS Conflict Resolution lib In-Reply-To: References: <403DBD52-4F3A-4C83-BE38-00B775D63918@redhat.com> Message-ID: > On Dec 16, 2014, at 4:22 AM, Luk?? Fry? wrote: > > Hey Luke, > > That seems sensible. I'm glad you are questioning this at the very beginning. > > JS conflict resolution in my eyes makes sense if we build some kind of ORM or three-way binding solution (we'd obviously create just client-model-to-server-model binding part, the rest is up to the MVC framework). > > I also believe that Conflict Resolution API shouldn't be much different from our Realtime sync from the API standpoint, > the real difference is that Conflict Resolution can easily intergrate with existing concepts and backends because of its RESTful nature, > while Realtime sync requires special backend handling (aka sync-server): > > Sync.save(objectInstance); > > > Additionally, Conflict Resolution has points on the roadmap that goes far behind regular framework principles: Partial Updates, Batch Updates, Server Notifications... > > As discussed on F2F, we should though always think about how this integrates into wider picture (existing frameworks). > > For this moment, we could start just with examples, they could also demonstrate us what deficiencies existing solutions have. > And if nothing, the only deliverable for conflict resolution at the end maybe a cookbook, a doc/guide and maybe some contributions to upstream :-) this might be a good start > > On Mon, Dec 15, 2014 at 5:31 PM, Lucas Holmquist > wrote: > So i have some concerns on the Current state of the conflit resolution POC that i created. > > in it's current state, i had 3 methods in the api > > * Read - just a GET > * Save - PUT/POST with an added "conflict" callback to handle the conflict resolution > * Remove - just a DELETE > > This was all done before we wrote this spec > > https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/ > > but even then, from the JS client perspective, it felt a lot like a pipe. In jQuery.ajax, you can actually listen for a "409". > > The other thing that concerns me is that on the client side, people are using frameworks such as Ember, Angular, Backbone,etc... that have there own ways of doing server requests so i would hate to start re-inveting the wheel again. > > while the read/remove don't really do anything different(they are just GET/DELETE's), the save method(PUT/POST) does. This is were all the "conflict resolution happens?. (what type on resolution algorithm, auto-merge, etc...) > > I think it would be interesting to try to integrate this part into existing frameworks, rather than trying to create Pipeline again. > > i think for node.js this might be interesting too, since we could create a piece of middleware that hooks into an express/connect request > > > Again, this might only be a concern on the JS client side, not sure what the other platforms are like in this regard > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141216/2d5b43f0/attachment-0001.html From agalante at redhat.com Tue Dec 16 14:15:39 2014 From: agalante at redhat.com (Andres Galante) Date: Tue, 16 Dec 2014 14:15:39 -0500 (EST) Subject: [aerogear-dev] Restructure Guides on Aerogear.org In-Reply-To: <737870887.1271365.1418757185107.JavaMail.zimbra@redhat.com> Message-ID: <1300641506.1271705.1418757339256.JavaMail.zimbra@redhat.com> On guides, there are some strange things happening on the way we structure things. For example: Ther is a Getting Started guides on the main index: https://aerogear.org/docs/guides/ and there are also getting started on the iOS guides https://aerogear.org/docs/guides/aerogear-ios/ Do you think its worth it for me to map the guides and re arrange them in a more consistent way for the new website? Like separate them per feature or per platform. From bruno at abstractj.org Tue Dec 16 14:28:41 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 16 Dec 2014 11:28:41 -0800 (PST) Subject: [aerogear-dev] Restructure Guides on Aerogear.org In-Reply-To: <1300641506.1271705.1418757339256.JavaMail.zimbra@redhat.com> References: <1300641506.1271705.1418757339256.JavaMail.zimbra@redhat.com> Message-ID: <1418758121010.9be19602@Nodemailer> +1 go for it ? abstractj PGP: 0x84DC9914 On Tue, Dec 16, 2014 at 5:15 PM, Andres Galante wrote: > On guides, there are some strange things happening on the way we structure things. > For example: > Ther is a Getting Started guides on the main index: > https://aerogear.org/docs/guides/ > and there are also getting started on the iOS guides > https://aerogear.org/docs/guides/aerogear-ios/ > Do you think its worth it for me to map the guides and re arrange them in a more consistent way for the new website? Like separate them per feature or per platform. > _______________________________________________ > 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/20141216/2939c8ed/attachment.html From corinnekrych at gmail.com Tue Dec 16 14:55:19 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 16 Dec 2014 20:55:19 +0100 Subject: [aerogear-dev] Restructure Guides on Aerogear.org In-Reply-To: <1418758121010.9be19602@Nodemailer> References: <1300641506.1271705.1418757339256.JavaMail.zimbra@redhat.com> <1418758121010.9be19602@Nodemailer> Message-ID: <79D7B0AD-5523-4B2D-9905-4A19F34DDD01@gmail.com> #agreed, restructuration of the docs is needed. ++ Corinne > On 16 Dec 2014, at 20:28, Bruno Oliveira wrote: > > +1 go for it > > ? > > abstractj > PGP: 0x84DC9914 > > > On Tue, Dec 16, 2014 at 5:15 PM, Andres Galante wrote: > > On guides, there are some strange things happening on the way we structure things. > > For example: > > Ther is a Getting Started guides on the main index: > https://aerogear.org/docs/guides/ > > and there are also getting started on the iOS guides > https://aerogear.org/docs/guides/aerogear-ios/ > > Do you think its worth it for me to map the guides and re arrange them in a more consistent way for the new website? Like separate them per feature or per platform. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 Dec 16 16:47:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 16 Dec 2014 22:47:59 +0100 Subject: [aerogear-dev] Restructure Guides on Aerogear.org In-Reply-To: <1300641506.1271705.1418757339256.JavaMail.zimbra@redhat.com> References: <737870887.1271365.1418757185107.JavaMail.zimbra@redhat.com> <1300641506.1271705.1418757339256.JavaMail.zimbra@redhat.com> Message-ID: On Tue, Dec 16, 2014 at 8:15 PM, Andres Galante wrote: > > On guides, there are some strange things happening on the way we structure > things. > +1 an overhaul on the structure is needed > > For example: > > Ther is a Getting Started guides on the main index: > https://aerogear.org/docs/guides/ > > and there are also getting started on the iOS guides > https://aerogear.org/docs/guides/aerogear-ios/ > > Do you think its worth it for me to map the guides and re arrange them in > a more consistent way for the new website? that would be very nice! > Like separate them per feature or per platform. > yeah, I think that's the tricky question. Perhaps per feature, and underneath per platform? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141216/b3f6a449/attachment.html From bruno at abstractj.org Tue Dec 16 17:00:09 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 16 Dec 2014 14:00:09 -0800 (PST) Subject: [aerogear-dev] Restructure Guides on Aerogear.org In-Reply-To: References: Message-ID: <1418767208874.85b107c2@Nodemailer> I vote per feature ? abstractj PGP: 0x84DC9914 On Tue, Dec 16, 2014 at 7:48 PM, Matthias Wessendorf wrote: > On Tue, Dec 16, 2014 at 8:15 PM, Andres Galante wrote: >> >> On guides, there are some strange things happening on the way we structure >> things. >> > +1 an overhaul on the structure is needed >> >> For example: >> >> Ther is a Getting Started guides on the main index: >> https://aerogear.org/docs/guides/ >> >> and there are also getting started on the iOS guides >> https://aerogear.org/docs/guides/aerogear-ios/ >> >> Do you think its worth it for me to map the guides and re arrange them in >> a more consistent way for the new website? > that would be very nice! >> Like separate them per feature or per platform. >> > yeah, I think that's the tricky question. Perhaps per feature, and > underneath per platform? >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141216/37e219fe/attachment.html From bruno at abstractj.org Tue Dec 16 17:17:01 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 16 Dec 2014 14:17:01 -0800 (PST) Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: References: Message-ID: <1418768221526.7ea1ac12@Nodemailer> Nice work! ? abstractj PGP: 0x84DC9914 On Tue, Dec 16, 2014 at 4:43 AM, Matthias Wessendorf wrote: > sounds good! > do you want to publish this (after the release) on the aerogear.org site ? > Sounds like a nice summary/post to me > On Tue, Dec 16, 2014 at 7:36 AM, Christos Vasilakis > wrote: >> >> Hi AeroGear community, >> >> we are happy to announce a pre-release of our various iOS libraries. Here >> are few of new features introduced in each respective list: >> >> - aerogear-ios-jsonsz >> (new) >> A newly introduced library which will take care the cumbersome plumbing >> required when performing JSON serialisation back and forth from your Swift >> object model. For an example usage of the library together with our >> http-lib check our Buddies cookbook example >> . >> - aerogear-ios-http >> We added the ability to perform basic/digest authentication when >> performing REST Requests. Check out our Authentication cookbook example >> , >> for an example usage of the API but remember to prefer HTTPS over plain >> HTTP when performing authentication of this type. >> >> - aerogear-ios-oauth2 >> Continuing the development of our OAuth2 library, OpenID Connect support >> was added to the library in the form of a ?login? request. Checkout out our ?SharedShoot? >> cookbook example >> that >> login's to KeyCloak using OpenID connect for >> an example usage. >> >> - aerogear-ios-httpstub >> >> Stubbed responses from the local file system can be used instead of coding >> them in your code. This will make easier to stub responses, especially big >> ones and be much ?closer? to the reality. Check out our tests >> for >> an example usage. >> >> >> Last, this release introduces Cocoapod support for >> our libraries. Although Cocoapods hasn?t yet officially support ?Swift? >> that is planned for the next 0.36 release, a branch >> on the project is >> working on it and already libraries starting to adopt. Just make sure to >> include a Gemfile in your project pointing to that cocoapods branch (see >> here for more >> detailed instructions) and in your Podfile include the desired library. For >> example usage, see our cookbook repository >> where all of our >> demos have been converted. >> >> So, give the libraries and demos a spin and let us know what you think. >> If no bad things heard we are planning to tag and officially release 2.1 >> this Friday. >> >> Have fun! >> >> Corinne & Christos >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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/20141216/f6de9a41/attachment-0001.html From agalante at redhat.com Tue Dec 16 17:31:03 2014 From: agalante at redhat.com (Andres Galante) Date: Tue, 16 Dec 2014 17:31:03 -0500 (EST) Subject: [aerogear-dev] Restructure Guides on Aerogear.org In-Reply-To: <1418767208874.85b107c2@Nodemailer> References: <1418767208874.85b107c2@Nodemailer> Message-ID: <2020293200.1286922.1418769063775.JavaMail.zimbra@redhat.com> I'll make a map tomorrow the current state and how it would be if we separate the docs, roadmaps, demos and guides per feature or per platform. I'll share it so we can build a solid structure together. ----- Original Message ----- From: "Bruno Oliveira" To: "AeroGear Developer Mailing List" Cc: "AeroGear Developer Mailing List" Sent: Tuesday, December 16, 2014 7:00:09 PM Subject: Re: [aerogear-dev] Restructure Guides on Aerogear.org I vote per feature ? abstractj PGP: 0x84DC9914 On Tue, Dec 16, 2014 at 7:48 PM, Matthias Wessendorf < matzew at apache.org > wrote: On Tue, Dec 16, 2014 at 8:15 PM, Andres Galante < agalante at redhat.com > wrote: On guides, there are some strange things happening on the way we structure things. +1 an overhaul on the structure is needed For example: Ther is a Getting Started guides on the main index: https://aerogear.org/docs/guides/ and there are also getting started on the iOS guides https://aerogear.org/docs/guides/aerogear-ios/ Do you think its worth it for me to map the guides and re arrange them in a more consistent way for the new website? that would be very nice! Like separate them per feature or per platform. yeah, I think that's the tricky question. Perhaps per feature, and underneath per platform? _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 Dec 17 08:37:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 17 Dec 2014 14:37:25 +0100 Subject: [aerogear-dev] [site] are these docs still needed ? Message-ID: Hi, looking at a few docs, I was wondering if they are still needed ? * AeroGear Pipelines and Pipes ( https://aerogear.org/docs/specs/aerogear-client-pipe/) --> Pipe's are specific to Android, and the behavior is documented in Android guide and could be also inside of the JavaDoc * Client Paging (https://aerogear.org/docs/specs/aerogear-client-paging/ and https://aerogear.org/docs/specs/aerogear-client-paging-usage/) --> My feeling is like above, specific to Android, no need to have this 'spec' Wanna get rid of them ? -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/20141217/50cc4aeb/attachment.html From lholmqui at redhat.com Wed Dec 17 08:43:34 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 17 Dec 2014 08:43:34 -0500 Subject: [aerogear-dev] [site] are these docs still needed ? In-Reply-To: References: Message-ID: <2B41E087-51A3-4F98-84FC-05724F8E40DE@redhat.com> > On Dec 17, 2014, at 8:37 AM, Matthias Wessendorf wrote: > > Hi, > > looking at a few docs, I was wondering if they are still needed ? > > > * AeroGear Pipelines and Pipes (https://aerogear.org/docs/specs/aerogear-client-pipe/ ) > --> Pipe's are specific to Android, and the behavior is documented in Android guide and could be also inside of the JavaDoc > if it?s possible to actually burn them with fire, then lets do that. if not, we can just delete them i guess :) > * Client Paging (https://aerogear.org/docs/specs/aerogear-client-paging/ and https://aerogear.org/docs/specs/aerogear-client-paging-usage/ ) > --> My feeling is like above, specific to Android, no need to have this 'spec' > > Wanna get rid of them ? > > -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/20141217/da951726/attachment.html From matzew at apache.org Wed Dec 17 09:02:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 17 Dec 2014 15:02:53 +0100 Subject: [aerogear-dev] User guide? In-Reply-To: <20141215175603.GB38140@abstractj.org> References: <20141215171618.GA38140@abstractj.org> <20141215175603.GB38140@abstractj.org> Message-ID: On Mon, Dec 15, 2014 at 6:56 PM, Bruno Oliveira wrote: > > But that would be more like an AeroGear security user guide, no? > > yes! I like that > Or I can just leave it as is. > > On 2014-12-15, Matthias Wessendorf wrote: > > not sure, if it does make sense. > > > > How about starting with a 'user guide' around our next big offerings > around > > OAuth2, covering all our supported platforms and services? Does that make > > sense? > > > > > > > > On Mon, Dec 15, 2014 at 6:16 PM, Bruno Oliveira > wrote: > > > > > > > > > Good morning, while reviewing some docs I started to consider to build > > > an AeroGear security user guide. At the same time I was wondering if > > > instead worth to build an AeroGear user guide with security being one > of > > > the chapters. > > > > > > The goal is to centralize que information in a single document. Into > > > this way people can read about it in ebook format or not. > > > > > > Does it worth the effort? > > > > > > -- > > > > > > 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/20141217/949fb992/attachment.html From matzew at apache.org Wed Dec 17 09:15:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 17 Dec 2014 15:15:38 +0100 Subject: [aerogear-dev] SITE: API Documentation and Specifications Message-ID: Hi, looking at andresgalante's long and scary list ( https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/current.markdown ) I think for the "API Documentation and Specifications", we could perhaps break that down into two differrent things: #API Documentations ##Mobile SDK API Documentation (not sure about the name) * AeroGear JS 2.0.0 * AeroGear iOS Http v0.1 * AeroGear iOS Oauth2 v0.1 * AeroGear-Push iOS 1.0.0 * AeroGear-OTP iOS 1.0.0 * AeroGear-Crypto iOS 0.2.3 * AeroGear Android 1.4.0 * AeroGear Android Auth 2.0.0-alpha.1 * AeroGear Android Authz 2.0.0-alpha.1 * AeroGear Android Pipe 2.0.0-alpha.1 * AeroGear Android Push 2.0.0-alpha.1 * AeroGear Android Security 2.0.0-alpha.1 * AeroGear Android Store 2.0.0-alpha.1 * AeroGear Cordova (lacks version?) ##Push API Docs * AeroGear UnifiedPush RESTful APIs - stable * AeroGear UnifiedPush RESTful APIs - development * AeroGear UnifiedPush Java Client - Version 1.0.0 * AeroGear UnifiedPush Node.js Client (lacks version?) * AeroGear SimplePush Java Client (lacks version?) (yes, I removed some of the items, as I think they are not relevant in here (see earlier email)) #Specifications ##Sync Specifications * Client API Proposals * Server API Proposals These will be hopefully soon be gone and we have, similar to 'push' specific API Docs for Sync (client/server) Any thoughts ? -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/20141217/3f24faac/attachment.html From agalante at redhat.com Wed Dec 17 09:31:11 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 17 Dec 2014 09:31:11 -0500 (EST) Subject: [aerogear-dev] SITE: API Documentation and Specifications In-Reply-To: References: Message-ID: <1626392047.1337765.1418826671297.JavaMail.zimbra@redhat.com> Hi I've done a re arrange of things as i see fit [1]. I am sure its not the correct thing so please make changes here: https://docs.google.com/document/d/1CcYGrKLWzFnEgfR43YSxaHi4DRnf2t2p5qAniCgcVUg/edit?usp=sharing [1] https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/feature.markdown ----- Original Message ----- From: "Matthias Wessendorf" To: "AeroGear Developer Mailing List" Sent: Wednesday, December 17, 2014 11:15:38 AM Subject: [aerogear-dev] SITE: API Documentation and Specifications Hi, looking at andresgalante's long and scary list ( https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/current.markdown ) I think for the "API Documentation and Specifications", we could perhaps break that down into two differrent things: #API Documentations ##Mobile SDK API Documentation (not sure about the name) * AeroGear JS 2.0.0 * AeroGear iOS Http v0.1 * AeroGear iOS Oauth2 v0.1 * AeroGear-Push iOS 1.0.0 * AeroGear-OTP iOS 1.0.0 * AeroGear-Crypto iOS 0.2.3 * AeroGear Android 1.4.0 * AeroGear Android Auth 2.0.0-alpha.1 * AeroGear Android Authz 2.0.0-alpha.1 * AeroGear Android Pipe 2.0.0-alpha.1 * AeroGear Android Push 2.0.0-alpha.1 * AeroGear Android Security 2.0.0-alpha.1 * AeroGear Android Store 2.0.0-alpha.1 * AeroGear Cordova (lacks version?) ##Push API Docs * AeroGear UnifiedPush RESTful APIs - stable * AeroGear UnifiedPush RESTful APIs - development * AeroGear UnifiedPush Java Client - Version 1.0.0 * AeroGear UnifiedPush Node.js Client (lacks version?) * AeroGear SimplePush Java Client (lacks version?) (yes, I removed some of the items, as I think they are not relevant in here (see earlier email)) #Specifications ##Sync Specifications * Client API Proposals * Server API Proposals These will be hopefully soon be gone and we have, similar to 'push' specific API Docs for Sync (client/server) Any thoughts ? -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 From bruno at abstractj.org Wed Dec 17 10:03:27 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 17 Dec 2014 13:03:27 -0200 Subject: [aerogear-dev] SITE: API Documentation and Specifications In-Reply-To: <1626392047.1337765.1418826671297.JavaMail.zimbra@redhat.com> References: <1626392047.1337765.1418826671297.JavaMail.zimbra@redhat.com> Message-ID: <20141217150327.GA75297@abstractj.org> Before I do big changes at the document I would like to suggest something like this for security: https://gist.github.com/abstractj/78bd79b47be666b3b355 The motivation of separate it per functionality/feature is to provide at the security user guide an introduction about each topic, gotchas and etc. Thoughts? On 2014-12-17, Andres Galante wrote: > Hi > > I've done a re arrange of things as i see fit [1]. I am sure its not the correct thing so please make changes here: > > https://docs.google.com/document/d/1CcYGrKLWzFnEgfR43YSxaHi4DRnf2t2p5qAniCgcVUg/edit?usp=sharing > > [1] https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/feature.markdown > > > ----- Original Message ----- > From: "Matthias Wessendorf" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 17, 2014 11:15:38 AM > Subject: [aerogear-dev] SITE: API Documentation and Specifications > > Hi, > > looking at andresgalante's long and scary list ( https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/current.markdown ) > > I think for the "API Documentation and Specifications", we could perhaps break that down into two differrent things: > > #API Documentations > > ##Mobile SDK API Documentation (not sure about the name) > * AeroGear JS 2.0.0 > * AeroGear iOS Http v0.1 > * AeroGear iOS Oauth2 v0.1 > * AeroGear-Push iOS 1.0.0 > * AeroGear-OTP iOS 1.0.0 > * AeroGear-Crypto iOS 0.2.3 > * AeroGear Android 1.4.0 > * AeroGear Android Auth 2.0.0-alpha.1 > * AeroGear Android Authz 2.0.0-alpha.1 > * AeroGear Android Pipe 2.0.0-alpha.1 > * AeroGear Android Push 2.0.0-alpha.1 > * AeroGear Android Security 2.0.0-alpha.1 > * AeroGear Android Store 2.0.0-alpha.1 > * AeroGear Cordova (lacks version?) > > ##Push API Docs > * AeroGear UnifiedPush RESTful APIs - stable > * AeroGear UnifiedPush RESTful APIs - development > * AeroGear UnifiedPush Java Client - Version 1.0.0 > * AeroGear UnifiedPush Node.js Client (lacks version?) > * AeroGear SimplePush Java Client (lacks version?) > > (yes, I removed some of the items, as I think they are not relevant in here (see earlier email)) > > > #Specifications > > ##Sync Specifications > * Client API Proposals > * Server API Proposals > > > These will be hopefully soon be gone and we have, similar to 'push' specific API Docs for Sync (client/server) > > > Any thoughts ? > > -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 -- abstractj PGP: 0x84DC9914 From agalante at redhat.com Wed Dec 17 10:28:30 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 17 Dec 2014 10:28:30 -0500 (EST) Subject: [aerogear-dev] SITE: API Documentation and Specifications In-Reply-To: <20141217150327.GA75297@abstractj.org> References: <1626392047.1337765.1418826671297.JavaMail.zimbra@redhat.com> <20141217150327.GA75297@abstractj.org> Message-ID: <1039817695.1348307.1418830110307.JavaMail.zimbra@redhat.com> Bruno if you think thats a better way to display security docs then I am for it! Should we do the same for Security guides? Do you think we should remove sub groups per platforms on the other features also? ----- Original Message ----- From: "Bruno Oliveira" To: "AeroGear Developer Mailing List" Sent: Wednesday, December 17, 2014 12:03:27 PM Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications Before I do big changes at the document I would like to suggest something like this for security: https://gist.github.com/abstractj/78bd79b47be666b3b355 The motivation of separate it per functionality/feature is to provide at the security user guide an introduction about each topic, gotchas and etc. Thoughts? On 2014-12-17, Andres Galante wrote: > Hi > > I've done a re arrange of things as i see fit [1]. I am sure its not the correct thing so please make changes here: > > https://docs.google.com/document/d/1CcYGrKLWzFnEgfR43YSxaHi4DRnf2t2p5qAniCgcVUg/edit?usp=sharing > > [1] https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/feature.markdown > > > ----- Original Message ----- > From: "Matthias Wessendorf" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 17, 2014 11:15:38 AM > Subject: [aerogear-dev] SITE: API Documentation and Specifications > > Hi, > > looking at andresgalante's long and scary list ( https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/current.markdown ) > > I think for the "API Documentation and Specifications", we could perhaps break that down into two differrent things: > > #API Documentations > > ##Mobile SDK API Documentation (not sure about the name) > * AeroGear JS 2.0.0 > * AeroGear iOS Http v0.1 > * AeroGear iOS Oauth2 v0.1 > * AeroGear-Push iOS 1.0.0 > * AeroGear-OTP iOS 1.0.0 > * AeroGear-Crypto iOS 0.2.3 > * AeroGear Android 1.4.0 > * AeroGear Android Auth 2.0.0-alpha.1 > * AeroGear Android Authz 2.0.0-alpha.1 > * AeroGear Android Pipe 2.0.0-alpha.1 > * AeroGear Android Push 2.0.0-alpha.1 > * AeroGear Android Security 2.0.0-alpha.1 > * AeroGear Android Store 2.0.0-alpha.1 > * AeroGear Cordova (lacks version?) > > ##Push API Docs > * AeroGear UnifiedPush RESTful APIs - stable > * AeroGear UnifiedPush RESTful APIs - development > * AeroGear UnifiedPush Java Client - Version 1.0.0 > * AeroGear UnifiedPush Node.js Client (lacks version?) > * AeroGear SimplePush Java Client (lacks version?) > > (yes, I removed some of the items, as I think they are not relevant in here (see earlier email)) > > > #Specifications > > ##Sync Specifications > * Client API Proposals > * Server API Proposals > > > These will be hopefully soon be gone and we have, similar to 'push' specific API Docs for Sync (client/server) > > > Any thoughts ? > > -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 -- abstractj PGP: 0x84DC9914 _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From agalante at redhat.com Wed Dec 17 10:47:54 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 17 Dec 2014 10:47:54 -0500 (EST) Subject: [aerogear-dev] SITE: API Documentation and Specifications In-Reply-To: <1039817695.1348307.1418830110307.JavaMail.zimbra@redhat.com> References: <1626392047.1337765.1418826671297.JavaMail.zimbra@redhat.com> <20141217150327.GA75297@abstractj.org> <1039817695.1348307.1418830110307.JavaMail.zimbra@redhat.com> Message-ID: <609964816.1350452.1418831274108.JavaMail.zimbra@redhat.com> I moved things to a gist: https://gist.github.com/andresgalante/078caebe08b11e259660 ----- Original Message ----- From: "Andres Galante" To: "AeroGear Developer Mailing List" Sent: Wednesday, December 17, 2014 12:28:30 PM Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications Bruno if you think thats a better way to display security docs then I am for it! Should we do the same for Security guides? Do you think we should remove sub groups per platforms on the other features also? ----- Original Message ----- From: "Bruno Oliveira" To: "AeroGear Developer Mailing List" Sent: Wednesday, December 17, 2014 12:03:27 PM Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications Before I do big changes at the document I would like to suggest something like this for security: https://gist.github.com/abstractj/78bd79b47be666b3b355 The motivation of separate it per functionality/feature is to provide at the security user guide an introduction about each topic, gotchas and etc. Thoughts? On 2014-12-17, Andres Galante wrote: > Hi > > I've done a re arrange of things as i see fit [1]. I am sure its not the correct thing so please make changes here: > > https://docs.google.com/document/d/1CcYGrKLWzFnEgfR43YSxaHi4DRnf2t2p5qAniCgcVUg/edit?usp=sharing > > [1] https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/feature.markdown > > > ----- Original Message ----- > From: "Matthias Wessendorf" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 17, 2014 11:15:38 AM > Subject: [aerogear-dev] SITE: API Documentation and Specifications > > Hi, > > looking at andresgalante's long and scary list ( https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/current.markdown ) > > I think for the "API Documentation and Specifications", we could perhaps break that down into two differrent things: > > #API Documentations > > ##Mobile SDK API Documentation (not sure about the name) > * AeroGear JS 2.0.0 > * AeroGear iOS Http v0.1 > * AeroGear iOS Oauth2 v0.1 > * AeroGear-Push iOS 1.0.0 > * AeroGear-OTP iOS 1.0.0 > * AeroGear-Crypto iOS 0.2.3 > * AeroGear Android 1.4.0 > * AeroGear Android Auth 2.0.0-alpha.1 > * AeroGear Android Authz 2.0.0-alpha.1 > * AeroGear Android Pipe 2.0.0-alpha.1 > * AeroGear Android Push 2.0.0-alpha.1 > * AeroGear Android Security 2.0.0-alpha.1 > * AeroGear Android Store 2.0.0-alpha.1 > * AeroGear Cordova (lacks version?) > > ##Push API Docs > * AeroGear UnifiedPush RESTful APIs - stable > * AeroGear UnifiedPush RESTful APIs - development > * AeroGear UnifiedPush Java Client - Version 1.0.0 > * AeroGear UnifiedPush Node.js Client (lacks version?) > * AeroGear SimplePush Java Client (lacks version?) > > (yes, I removed some of the items, as I think they are not relevant in here (see earlier email)) > > > #Specifications > > ##Sync Specifications > * Client API Proposals > * Server API Proposals > > > These will be hopefully soon be gone and we have, similar to 'push' specific API Docs for Sync (client/server) > > > Any thoughts ? > > -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 -- 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 bruno at abstractj.org Wed Dec 17 11:22:46 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 17 Dec 2014 14:22:46 -0200 Subject: [aerogear-dev] SITE: API Documentation and Specifications In-Reply-To: <609964816.1350452.1418831274108.JavaMail.zimbra@redhat.com> References: <1626392047.1337765.1418826671297.JavaMail.zimbra@redhat.com> <20141217150327.GA75297@abstractj.org> <1039817695.1348307.1418830110307.JavaMail.zimbra@redhat.com> <609964816.1350452.1418831274108.JavaMail.zimbra@redhat.com> Message-ID: <20141217162246.GA76030@abstractj.org> Ahoy my friend, I will add my proposal for security and also change the guides. To make it easy I created a branch "newstructure" https://github.com/aerogear/aerogear.org/commit/ab2b72a28b5485982f1a65919e0263ec43f120b1. Into this way people can submit pull requests, others review and provide some input. On 2014-12-17, Andres Galante wrote: > I moved things to a gist: > > https://gist.github.com/andresgalante/078caebe08b11e259660 > > > > ----- Original Message ----- > From: "Andres Galante" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 17, 2014 12:28:30 PM > Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications > > Bruno if you think thats a better way to display security docs then I am for it! > Should we do the same for Security guides? > > Do you think we should remove sub groups per platforms on the other features also? > > > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 17, 2014 12:03:27 PM > Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications > > Before I do big changes at the document I would like to suggest > something like this for security: > https://gist.github.com/abstractj/78bd79b47be666b3b355 > > The motivation of separate it per functionality/feature is to provide at > the security user guide an introduction about each topic, gotchas and > etc. > > Thoughts? > > On 2014-12-17, Andres Galante wrote: > > Hi > > > > I've done a re arrange of things as i see fit [1]. I am sure its not the correct thing so please make changes here: > > > > https://docs.google.com/document/d/1CcYGrKLWzFnEgfR43YSxaHi4DRnf2t2p5qAniCgcVUg/edit?usp=sharing > > > > [1] https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/feature.markdown > > > > > > ----- Original Message ----- > > From: "Matthias Wessendorf" > > To: "AeroGear Developer Mailing List" > > Sent: Wednesday, December 17, 2014 11:15:38 AM > > Subject: [aerogear-dev] SITE: API Documentation and Specifications > > > > Hi, > > > > looking at andresgalante's long and scary list ( https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/current.markdown ) > > > > I think for the "API Documentation and Specifications", we could perhaps break that down into two differrent things: > > > > #API Documentations > > > > ##Mobile SDK API Documentation (not sure about the name) > > * AeroGear JS 2.0.0 > > * AeroGear iOS Http v0.1 > > * AeroGear iOS Oauth2 v0.1 > > * AeroGear-Push iOS 1.0.0 > > * AeroGear-OTP iOS 1.0.0 > > * AeroGear-Crypto iOS 0.2.3 > > * AeroGear Android 1.4.0 > > * AeroGear Android Auth 2.0.0-alpha.1 > > * AeroGear Android Authz 2.0.0-alpha.1 > > * AeroGear Android Pipe 2.0.0-alpha.1 > > * AeroGear Android Push 2.0.0-alpha.1 > > * AeroGear Android Security 2.0.0-alpha.1 > > * AeroGear Android Store 2.0.0-alpha.1 > > * AeroGear Cordova (lacks version?) > > > > ##Push API Docs > > * AeroGear UnifiedPush RESTful APIs - stable > > * AeroGear UnifiedPush RESTful APIs - development > > * AeroGear UnifiedPush Java Client - Version 1.0.0 > > * AeroGear UnifiedPush Node.js Client (lacks version?) > > * AeroGear SimplePush Java Client (lacks version?) > > > > (yes, I removed some of the items, as I think they are not relevant in here (see earlier email)) > > > > > > #Specifications > > > > ##Sync Specifications > > * Client API Proposals > > * Server API Proposals > > > > > > These will be hopefully soon be gone and we have, similar to 'push' specific API Docs for Sync (client/server) > > > > > > Any thoughts ? > > > > -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 > > -- > > 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From agalante at redhat.com Wed Dec 17 11:40:54 2014 From: agalante at redhat.com (Andres Galante) Date: Wed, 17 Dec 2014 11:40:54 -0500 (EST) Subject: [aerogear-dev] wording change In-Reply-To: <2115237763.1355131.1418834228031.JavaMail.zimbra@redhat.com> Message-ID: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> I've shared the new website at the UX team meeting today. They think think that we should change the word "features" to "solutions" or "components". It seems that it is hard to understand that aerogear is actually 4 different products and the word "features" doesn't reflect that. What do you think? From matzew at apache.org Thu Dec 18 07:23:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 18 Dec 2014 13:23:08 +0100 Subject: [aerogear-dev] wording change In-Reply-To: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> References: <2115237763.1355131.1418834228031.JavaMail.zimbra@redhat.com> <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Dec 17, 2014 at 5:40 PM, Andres Galante wrote: > > I've shared the new website at the UX team meeting today. > > They think think that we should change the word "features" to "solutions" > or "components". > I like solutions > > It seems that it is hard to understand that aerogear is actually 4 > different products how comes the number of four ? we have several 'solutions' out. Like: * SimplePush Server * UnifiedPush Server And in progress in progress: * OAuth2 (client libraries for Android, Cordova and OS) * Sync Server * WebPush Server Besides that, we do have solid client APIs for mobile platforms like Android and iOS (e.g. http API layer ). We also have security features/solutions, like our own TOTP support (Android + iOS) > and the word "features" doesn't reflect that. > > What do you think? > Glad you are looking into all this. I am now reflecting that it was actually overdue to work on homepage improvements. Great job Andres -M > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141218/71625a5c/attachment-0001.html From agalante at redhat.com Thu Dec 18 07:33:15 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 18 Dec 2014 07:33:15 -0500 (EST) Subject: [aerogear-dev] wording change In-Reply-To: References: <2115237763.1355131.1418834228031.JavaMail.zimbra@redhat.com> <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> Message-ID: <892666460.74127.1418905995938.JavaMail.zimbra@redhat.com> The 4 solutions comes from the way we separate things on the website: Aerogear Core Aerogear Sync Aerogear Security Aerogear Push Does it makes sense? On website I have removed the top bar for search and repo and did a lot of small changes everywhere. I will restructure today guides and docs, plus if you go to community you can see our faces :) https://github.com/andresgalante/aerogear.org/tree/new-design ----- Original Message ----- From: "Matthias Wessendorf" To: "AeroGear Developer Mailing List" Sent: Thursday, December 18, 2014 9:23:08 AM Subject: Re: [aerogear-dev] wording change On Wed, Dec 17, 2014 at 5:40 PM, Andres Galante < agalante at redhat.com > wrote: I've shared the new website at the UX team meeting today. They think think that we should change the word "features" to "solutions" or "components". I like solutions It seems that it is hard to understand that aerogear is actually 4 different products how comes the number of four ? we have several 'solutions' out. Like: * SimplePush Server * UnifiedPush Server And in progress in progress: * OAuth2 (client libraries for Android, Cordova and OS) * Sync Server * WebPush Server Besides that, we do have solid client APIs for mobile platforms like Android and iOS (e.g. http API layer ). We also have security features/solutions, like our own TOTP support (Android + iOS) and the word "features" doesn't reflect that. What do you think? Glad you are looking into all this. I am now reflecting that it was actually overdue to work on homepage improvements. Great job Andres -M _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.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 edewit at redhat.com Thu Dec 18 08:09:49 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 18 Dec 2014 14:09:49 +0100 Subject: [aerogear-dev] wording change In-Reply-To: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> References: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> Message-ID: <5492D21D.5040903@redhat.com> On 17/12/2014 17:40, Andres Galante wrote: > I've shared the new website at the UX team meeting today. > > They think think that we should change the word "features" to "solutions" or "components". I hate "solutions" with a passion, and "components" is not the right word. How about "modules" or "sub-projects" > > It seems that it is hard to understand that aerogear is actually 4 different products and the word "features" doesn't reflect that. > > What do you think? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From agalante at redhat.com Thu Dec 18 08:33:28 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 18 Dec 2014 08:33:28 -0500 (EST) Subject: [aerogear-dev] wording change In-Reply-To: <5492D21D.5040903@redhat.com> References: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> <5492D21D.5040903@redhat.com> Message-ID: <597800627.79510.1418909608315.JavaMail.zimbra@redhat.com> I like them, both "modules" and "sub-projects" are better than "features". ----- Original Message ----- From: "Erik Jan de Wit" To: aerogear-dev at lists.jboss.org Sent: Thursday, December 18, 2014 10:09:49 AM Subject: Re: [aerogear-dev] wording change On 17/12/2014 17:40, Andres Galante wrote: > I've shared the new website at the UX team meeting today. > > They think think that we should change the word "features" to "solutions" or "components". I hate "solutions" with a passion, and "components" is not the right word. How about "modules" or "sub-projects" > > It seems that it is hard to understand that aerogear is actually 4 different products and the word "features" doesn't reflect that. > > What do you think? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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 Dec 18 09:09:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 18 Dec 2014 15:09:16 +0100 Subject: [aerogear-dev] wording change In-Reply-To: <597800627.79510.1418909608315.JavaMail.zimbra@redhat.com> References: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> <5492D21D.5040903@redhat.com> <597800627.79510.1418909608315.JavaMail.zimbra@redhat.com> Message-ID: On Thu, Dec 18, 2014 at 2:33 PM, Andres Galante wrote: > > I like them, both "modules" I like modules (and solutions :-)) > and "sub-projects" are better than "features". > > > > ----- Original Message ----- > From: "Erik Jan de Wit" > To: aerogear-dev at lists.jboss.org > Sent: Thursday, December 18, 2014 10:09:49 AM > Subject: Re: [aerogear-dev] wording change > > > On 17/12/2014 17:40, Andres Galante wrote: > > I've shared the new website at the UX team meeting today. > > > > They think think that we should change the word "features" to > "solutions" or "components". > > I hate "solutions" with a passion, and "components" is not the right > word. How about "modules" or "sub-projects" > > > > > It seems that it is hard to understand that aerogear is actually 4 > different products and the word "features" doesn't reflect that. > > > > What do you think? > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.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/20141218/8be79ae9/attachment.html From agalante at redhat.com Thu Dec 18 13:30:15 2014 From: agalante at redhat.com (Andres Galante) Date: Thu, 18 Dec 2014 13:30:15 -0500 (EST) Subject: [aerogear-dev] SITE: API Documentation and Specifications In-Reply-To: <20141217162246.GA76030@abstractj.org> References: <1626392047.1337765.1418826671297.JavaMail.zimbra@redhat.com> <20141217150327.GA75297@abstractj.org> <1039817695.1348307.1418830110307.JavaMail.zimbra@redhat.com> <609964816.1350452.1418831274108.JavaMail.zimbra@redhat.com> <20141217162246.GA76030@abstractj.org> Message-ID: <715960316.121123.1418927415940.JavaMail.zimbra@redhat.com> I have updated the repo with the changes on structure we talked about. https://github.com/andresgalante/aerogear.org/tree/new-design Please check out Guides (under getting started) and Documentation Specs (under Docs) indexes, if you can help me figure that out I'll take care of putting the rest of the files together. Thanks! ----- Original Message ----- From: "Bruno Oliveira" To: "AeroGear Developer Mailing List" Sent: Wednesday, December 17, 2014 1:22:46 PM Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications Ahoy my friend, I will add my proposal for security and also change the guides. To make it easy I created a branch "newstructure" https://github.com/aerogear/aerogear.org/commit/ab2b72a28b5485982f1a65919e0263ec43f120b1. Into this way people can submit pull requests, others review and provide some input. On 2014-12-17, Andres Galante wrote: > I moved things to a gist: > > https://gist.github.com/andresgalante/078caebe08b11e259660 > > > > ----- Original Message ----- > From: "Andres Galante" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 17, 2014 12:28:30 PM > Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications > > Bruno if you think thats a better way to display security docs then I am for it! > Should we do the same for Security guides? > > Do you think we should remove sub groups per platforms on the other features also? > > > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 17, 2014 12:03:27 PM > Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications > > Before I do big changes at the document I would like to suggest > something like this for security: > https://gist.github.com/abstractj/78bd79b47be666b3b355 > > The motivation of separate it per functionality/feature is to provide at > the security user guide an introduction about each topic, gotchas and > etc. > > Thoughts? > > On 2014-12-17, Andres Galante wrote: > > Hi > > > > I've done a re arrange of things as i see fit [1]. I am sure its not the correct thing so please make changes here: > > > > https://docs.google.com/document/d/1CcYGrKLWzFnEgfR43YSxaHi4DRnf2t2p5qAniCgcVUg/edit?usp=sharing > > > > [1] https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/feature.markdown > > > > > > ----- Original Message ----- > > From: "Matthias Wessendorf" > > To: "AeroGear Developer Mailing List" > > Sent: Wednesday, December 17, 2014 11:15:38 AM > > Subject: [aerogear-dev] SITE: API Documentation and Specifications > > > > Hi, > > > > looking at andresgalante's long and scary list ( https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/current.markdown ) > > > > I think for the "API Documentation and Specifications", we could perhaps break that down into two differrent things: > > > > #API Documentations > > > > ##Mobile SDK API Documentation (not sure about the name) > > * AeroGear JS 2.0.0 > > * AeroGear iOS Http v0.1 > > * AeroGear iOS Oauth2 v0.1 > > * AeroGear-Push iOS 1.0.0 > > * AeroGear-OTP iOS 1.0.0 > > * AeroGear-Crypto iOS 0.2.3 > > * AeroGear Android 1.4.0 > > * AeroGear Android Auth 2.0.0-alpha.1 > > * AeroGear Android Authz 2.0.0-alpha.1 > > * AeroGear Android Pipe 2.0.0-alpha.1 > > * AeroGear Android Push 2.0.0-alpha.1 > > * AeroGear Android Security 2.0.0-alpha.1 > > * AeroGear Android Store 2.0.0-alpha.1 > > * AeroGear Cordova (lacks version?) > > > > ##Push API Docs > > * AeroGear UnifiedPush RESTful APIs - stable > > * AeroGear UnifiedPush RESTful APIs - development > > * AeroGear UnifiedPush Java Client - Version 1.0.0 > > * AeroGear UnifiedPush Node.js Client (lacks version?) > > * AeroGear SimplePush Java Client (lacks version?) > > > > (yes, I removed some of the items, as I think they are not relevant in here (see earlier email)) > > > > > > #Specifications > > > > ##Sync Specifications > > * Client API Proposals > > * Server API Proposals > > > > > > These will be hopefully soon be gone and we have, similar to 'push' specific API Docs for Sync (client/server) > > > > > > Any thoughts ? > > > > -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 > > -- > > 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 > _______________________________________________ > 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 bruno at abstractj.org Thu Dec 18 13:50:53 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 18 Dec 2014 16:50:53 -0200 Subject: [aerogear-dev] SITE: API Documentation and Specifications In-Reply-To: <715960316.121123.1418927415940.JavaMail.zimbra@redhat.com> References: <1626392047.1337765.1418826671297.JavaMail.zimbra@redhat.com> <20141217150327.GA75297@abstractj.org> <1039817695.1348307.1418830110307.JavaMail.zimbra@redhat.com> <609964816.1350452.1418831274108.JavaMail.zimbra@redhat.com> <20141217162246.GA76030@abstractj.org> <715960316.121123.1418927415940.JavaMail.zimbra@redhat.com> Message-ID: Ahoy my friend, I created the following branch on AeroGear https://github.com/aerogear/aerogear.org/tree/new-design. Into this way you can submit your change against the website repo On Thu, Dec 18, 2014 at 4:30 PM, Andres Galante wrote: > > I have updated the repo with the changes on structure we talked about. > > https://github.com/andresgalante/aerogear.org/tree/new-design > > Please check out Guides (under getting started) and Documentation Specs > (under Docs) indexes, if you can help me figure that out I'll take care of > putting the rest of the files together. > > Thanks! > > > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, December 17, 2014 1:22:46 PM > Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications > > Ahoy my friend, I will add my proposal for security and also change the > guides. > > To make it easy I created a branch "newstructure" > > https://github.com/aerogear/aerogear.org/commit/ab2b72a28b5485982f1a65919e0263ec43f120b1 > . > > Into this way people can submit pull requests, others review and provide > some input. > > On 2014-12-17, Andres Galante wrote: > > I moved things to a gist: > > > > https://gist.github.com/andresgalante/078caebe08b11e259660 > > > > > > > > ----- Original Message ----- > > From: "Andres Galante" > > To: "AeroGear Developer Mailing List" > > Sent: Wednesday, December 17, 2014 12:28:30 PM > > Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications > > > > Bruno if you think thats a better way to display security docs then I am > for it! > > Should we do the same for Security guides? > > > > Do you think we should remove sub groups per platforms on the other > features also? > > > > > > > > ----- Original Message ----- > > From: "Bruno Oliveira" > > To: "AeroGear Developer Mailing List" > > Sent: Wednesday, December 17, 2014 12:03:27 PM > > Subject: Re: [aerogear-dev] SITE: API Documentation and Specifications > > > > Before I do big changes at the document I would like to suggest > > something like this for security: > > https://gist.github.com/abstractj/78bd79b47be666b3b355 > > > > The motivation of separate it per functionality/feature is to provide at > > the security user guide an introduction about each topic, gotchas and > > etc. > > > > Thoughts? > > > > On 2014-12-17, Andres Galante wrote: > > > Hi > > > > > > I've done a re arrange of things as i see fit [1]. I am sure its not > the correct thing so please make changes here: > > > > > > > https://docs.google.com/document/d/1CcYGrKLWzFnEgfR43YSxaHi4DRnf2t2p5qAniCgcVUg/edit?usp=sharing > > > > > > [1] > https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/feature.markdown > > > > > > > > > ----- Original Message ----- > > > From: "Matthias Wessendorf" > > > To: "AeroGear Developer Mailing List" > > > Sent: Wednesday, December 17, 2014 11:15:38 AM > > > Subject: [aerogear-dev] SITE: API Documentation and Specifications > > > > > > Hi, > > > > > > looking at andresgalante's long and scary list ( > https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structure/current.markdown > ) > > > > > > I think for the "API Documentation and Specifications", we could > perhaps break that down into two differrent things: > > > > > > #API Documentations > > > > > > ##Mobile SDK API Documentation (not sure about the name) > > > * AeroGear JS 2.0.0 > > > * AeroGear iOS Http v0.1 > > > * AeroGear iOS Oauth2 v0.1 > > > * AeroGear-Push iOS 1.0.0 > > > * AeroGear-OTP iOS 1.0.0 > > > * AeroGear-Crypto iOS 0.2.3 > > > * AeroGear Android 1.4.0 > > > * AeroGear Android Auth 2.0.0-alpha.1 > > > * AeroGear Android Authz 2.0.0-alpha.1 > > > * AeroGear Android Pipe 2.0.0-alpha.1 > > > * AeroGear Android Push 2.0.0-alpha.1 > > > * AeroGear Android Security 2.0.0-alpha.1 > > > * AeroGear Android Store 2.0.0-alpha.1 > > > * AeroGear Cordova (lacks version?) > > > > > > ##Push API Docs > > > * AeroGear UnifiedPush RESTful APIs - stable > > > * AeroGear UnifiedPush RESTful APIs - development > > > * AeroGear UnifiedPush Java Client - Version 1.0.0 > > > * AeroGear UnifiedPush Node.js Client (lacks version?) > > > * AeroGear SimplePush Java Client (lacks version?) > > > > > > (yes, I removed some of the items, as I think they are not relevant in > here (see earlier email)) > > > > > > > > > #Specifications > > > > > > ##Sync Specifications > > > * Client API Proposals > > > * Server API Proposals > > > > > > > > > These will be hopefully soon be gone and we have, similar to 'push' > specific API Docs for Sync (client/server) > > > > > > > > > Any thoughts ? > > > > > > -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 > > > > -- > > > > 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 > > _______________________________________________ > > 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141218/6151085d/attachment-0001.html From corinnekrych at gmail.com Thu Dec 18 15:25:11 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 18 Dec 2014 21:25:11 +0100 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: References: Message-ID: <81204C25-6602-4972-8765-7F8B8867EC77@gmail.com> Hello iOS lovers, I?ve just found an issue with our aerogear-ios-http library [1] that we think is a blocker for our 2.1 release planned on Friday. The problem occurs when using Http object as local variable rather than instance variable, the root cause is the releasing of NSURLSession happening too early. But the problem brought to our attention some code confusion around the usage of the public API. We would like to fix the issue with some serious refactor. Where to go from here? After sitting down with Christos, we think a solid http ground is essential to support our oauth2 lib, we?ve got some ideas on how we want to refactor. This issue is our main priority and as soon as we?ve got a fix, we?ll do the release. Christos is already working full time on this refactor so we can deliver as soon as possible the next exciting version of our libs. If you have any questions, concerns, this is the thread to ask. ++ Corinne [1] https://issues.jboss.org/browse/AGIOS-325 > On 16 Dec 2014, at 07:36, Christos Vasilakis wrote: > > Hi AeroGear community, > > we are happy to announce a pre-release of our various iOS libraries. Here are few of new features introduced in each respective list: > > - aerogear-ios-jsonsz (new) > A newly introduced library which will take care the cumbersome plumbing required when performing JSON serialisation back and forth from your Swift object model. For an example usage of the library together with our http-lib check our Buddies cookbook example. > > - aerogear-ios-http > We added the ability to perform basic/digest authentication when performing REST Requests. Check out our Authentication cookbook example, for an example usage of the API but remember to prefer HTTPS over plain HTTP when performing authentication of this type. > > - aerogear-ios-oauth2 > Continuing the development of our OAuth2 library, OpenID Connect support was added to the library in the form of a ?login? request. Checkout out our ?SharedShoot? cookbook example that login's to KeyCloak using OpenID connect for an example usage. > > - aerogear-ios-httpstub > Stubbed responses from the local file system can be used instead of coding them in your code. This will make easier to stub responses, especially big ones and be much ?closer? to the reality. Check out our tests for an example usage. > > > Last, this release introduces Cocoapod support for our libraries. Although Cocoapods hasn?t yet officially support ?Swift? that is planned for the next 0.36 release, a branch on the project is working on it and already libraries starting to adopt. Just make sure to include a Gemfile in your project pointing to that cocoapods branch (see here for more detailed instructions) and in your Podfile include the desired library. For example usage, see our cookbook repository where all of our demos have been converted. > > So, give the libraries and demos a spin and let us know what you think. If no bad things heard we are planning to tag and officially release 2.1 this Friday. > > Have fun! > > Corinne & Christos > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Thu Dec 18 15:25:15 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 18 Dec 2014 18:25:15 -0200 Subject: [aerogear-dev] Cookbooks stable versions Message-ID: <20141218202515.GA90431@abstractj.org> Good morning team, After some discussion at this PR https://github.com/aerogear/aerogear-android-cookbook/pull/22. I was wondering if would be nice on having the zip files with the latest cookbook stable version. Like we do for UPS https://github.com/aerogear/aerogear-unifiedpush-server/releases This is not specific for Android, I saw that some projects are already doing it like AGJS, we just need to keep the pace. -- abstractj PGP: 0x84DC9914 From matzew at apache.org Thu Dec 18 17:18:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 18 Dec 2014 23:18:15 +0100 Subject: [aerogear-dev] Cookbooks stable versions In-Reply-To: <20141218202515.GA90431@abstractj.org> References: <20141218202515.GA90431@abstractj.org> Message-ID: Hello there! On Thu, Dec 18, 2014 at 9:25 PM, Bruno Oliveira wrote: > > Good morning team, > > After some discussion at this PR > https://github.com/aerogear/aerogear-android-cookbook/pull/22. I was > wondering if would be nice on having the zip files with the latest > cookbook stable version. Like we do for UPS > https://github.com/aerogear/aerogear-unifiedpush-server/releases I think it would be nice if the cookbook usage experience for our users is as simple as possible: - clone master - build the app - deploy - profit If our users would have to build a few dependency in order to get the cookbook demo(s) up and running, I am not sure if the experience is that smooth. +1 on creating tags/releases for the cookbooks. This could be done when the cookbook is upgraded to a new version of our libraries. Another benefit with creating these tags/releases is that this gives us a history(or list) of demos that also show how to use slightly older versions (e.g. from last year), instead of just the latest greatest. -Matthias > > > This is not specific for Android, I saw that some projects are already > doing it like AGJS, we just need to keep the pace. > > -- > > 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/20141218/42dd7a0c/attachment.html From daniel at passos.me Fri Dec 19 05:56:18 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 19 Dec 2014 08:56:18 -0200 Subject: [aerogear-dev] wording change In-Reply-To: References: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> <5492D21D.5040903@redhat.com> <597800627.79510.1418909608315.JavaMail.zimbra@redhat.com> Message-ID: +1 for modules On Thu, Dec 18, 2014 at 12:09 PM, Matthias Wessendorf wrote: > > > > On Thu, Dec 18, 2014 at 2:33 PM, Andres Galante > wrote: >> >> I like them, both "modules" > > > I like modules (and solutions :-)) > > >> and "sub-projects" are better than "features". >> >> >> >> ----- Original Message ----- >> From: "Erik Jan de Wit" >> To: aerogear-dev at lists.jboss.org >> Sent: Thursday, December 18, 2014 10:09:49 AM >> Subject: Re: [aerogear-dev] wording change >> >> >> On 17/12/2014 17:40, Andres Galante wrote: >> > I've shared the new website at the UX team meeting today. >> > >> > They think think that we should change the word "features" to >> "solutions" or "components". >> >> I hate "solutions" with a passion, and "components" is not the right >> word. How about "modules" or "sub-projects" >> >> > >> > It seems that it is hard to understand that aerogear is actually 4 >> different products and the word "features" doesn't reflect that. >> > >> > What do you think? >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.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/20141219/1e67db1c/attachment.html From daniel.bevenius at gmail.com Fri Dec 19 05:57:46 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 19 Dec 2014 11:57:46 +0100 Subject: [aerogear-dev] wording change In-Reply-To: References: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> <5492D21D.5040903@redhat.com> <597800627.79510.1418909608315.JavaMail.zimbra@redhat.com> Message-ID: +1 for modules On 19 December 2014 at 11:56, Daniel Passos wrote: > +1 for modules > > On Thu, Dec 18, 2014 at 12:09 PM, Matthias Wessendorf > wrote: >> >> >> >> On Thu, Dec 18, 2014 at 2:33 PM, Andres Galante >> wrote: >>> >>> I like them, both "modules" >> >> >> I like modules (and solutions :-)) >> >> >>> and "sub-projects" are better than "features". >>> >>> >>> >>> ----- Original Message ----- >>> From: "Erik Jan de Wit" >>> To: aerogear-dev at lists.jboss.org >>> Sent: Thursday, December 18, 2014 10:09:49 AM >>> Subject: Re: [aerogear-dev] wording change >>> >>> >>> On 17/12/2014 17:40, Andres Galante wrote: >>> > I've shared the new website at the UX team meeting today. >>> > >>> > They think think that we should change the word "features" to >>> "solutions" or "components". >>> >>> I hate "solutions" with a passion, and "components" is not the right >>> word. How about "modules" or "sub-projects" >>> >>> > >>> > It seems that it is hard to understand that aerogear is actually 4 >>> different products and the word "features" doesn't reflect that. >>> > >>> > What do you think? >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.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/20141219/399ac192/attachment-0001.html From daniel at passos.me Fri Dec 19 06:05:49 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 19 Dec 2014 09:05:49 -0200 Subject: [aerogear-dev] Restructure Guides on Aerogear.org In-Reply-To: <2020293200.1286922.1418769063775.JavaMail.zimbra@redhat.com> References: <1418767208874.85b107c2@Nodemailer> <2020293200.1286922.1418769063775.JavaMail.zimbra@redhat.com> Message-ID: Hi, Sorry for my delay. IMO this is a hard decision. I like our landing page[1] where developer have all information about some specific platform, btw will be awesome see how do the same in another platform. [1] aerogear.org/docs/guides/aerogear-android On Tue, Dec 16, 2014 at 8:31 PM, Andres Galante wrote: > > I'll make a map tomorrow the current state and how it would be if we > separate the docs, roadmaps, demos and guides per feature or per platform. > > I'll share it so we can build a solid structure together. > > > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "AeroGear Developer Mailing List" > Cc: "AeroGear Developer Mailing List" > Sent: Tuesday, December 16, 2014 7:00:09 PM > Subject: Re: [aerogear-dev] Restructure Guides on Aerogear.org > > I vote per feature > > ? > > abstractj > PGP: 0x84DC9914 > > > > > On Tue, Dec 16, 2014 at 7:48 PM, Matthias Wessendorf < matzew at apache.org > > wrote: > > > > > > On Tue, Dec 16, 2014 at 8:15 PM, Andres Galante < agalante at redhat.com > > wrote: > > On guides, there are some strange things happening on the way we structure > things. > > +1 an overhaul on the structure is needed > > > > For example: > > Ther is a Getting Started guides on the main index: > https://aerogear.org/docs/guides/ > > and there are also getting started on the iOS guides > https://aerogear.org/docs/guides/aerogear-ios/ > > Do you think its worth it for me to map the guides and re arrange them in > a more consistent way for the new website? > > that would be very nice! > > > Like separate them per feature or per platform. > > yeah, I think that's the tricky question. Perhaps per feature, and > underneath per platform? > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141219/a16f1d76/attachment.html From supittma at redhat.com Fri Dec 19 08:46:24 2014 From: supittma at redhat.com (Summers Pittman) Date: Fri, 19 Dec 2014 08:46:24 -0500 Subject: [aerogear-dev] wording change In-Reply-To: References: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> <5492D21D.5040903@redhat.com> <597800627.79510.1418909608315.JavaMail.zimbra@redhat.com> Message-ID: <54942C30.20805@redhat.com> +1 for modules On 12/19/2014 05:57 AM, Daniel Bevenius wrote: > +1 for modules > > On 19 December 2014 at 11:56, Daniel Passos > wrote: > > +1 for modules > > On Thu, Dec 18, 2014 at 12:09 PM, Matthias Wessendorf > > wrote: > > > > On Thu, Dec 18, 2014 at 2:33 PM, Andres Galante > > wrote: > > I like them, both "modules" > > > I like modules (and solutions :-)) > > and "sub-projects" are better than "features". > > > > ----- Original Message ----- > From: "Erik Jan de Wit" > > To: aerogear-dev at lists.jboss.org > > Sent: Thursday, December 18, 2014 10:09:49 AM > Subject: Re: [aerogear-dev] wording change > > > On 17/12/2014 17:40, Andres Galante wrote: > > I've shared the new website at the UX team meeting today. > > > > They think think that we should change the word > "features" to "solutions" or "components". > > I hate "solutions" with a passion, and "components" is not > the right > word. How about "modules" or "sub-projects" > > > > > It seems that it is hard to understand that aerogear is > actually 4 different products and the word "features" > doesn't reflect that. > > > > What do you think? > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > > https://lists.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 -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141219/f7700d14/attachment.html From lholmqui at redhat.com Fri Dec 19 09:17:28 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 19 Dec 2014 09:17:28 -0500 Subject: [aerogear-dev] wording change In-Reply-To: <54942C30.20805@redhat.com> References: <1751753593.1355641.1418834454846.JavaMail.zimbra@redhat.com> <5492D21D.5040903@redhat.com> <597800627.79510.1418909608315.JavaMail.zimbra@redhat.com> <54942C30.20805@redhat.com> Message-ID: <3753A802-5883-4F53-9169-FB8CEFFC1E95@redhat.com> Modules, Modules, Modules ( said in Best Steve Ballmer voice ) > On Dec 19, 2014, at 8:46 AM, Summers Pittman wrote: > > +1 for modules > On 12/19/2014 05:57 AM, Daniel Bevenius wrote: >> +1 for modules >> >> On 19 December 2014 at 11:56, Daniel Passos > wrote: >> +1 for modules >> >> On Thu, Dec 18, 2014 at 12:09 PM, Matthias Wessendorf > wrote: >> >> >> On Thu, Dec 18, 2014 at 2:33 PM, Andres Galante > wrote: >> I like them, both "modules" >> >> I like modules (and solutions :-)) >> >> and "sub-projects" are better than "features". >> >> >> >> ----- Original Message ----- >> From: "Erik Jan de Wit" > >> To: aerogear-dev at lists.jboss.org >> Sent: Thursday, December 18, 2014 10:09:49 AM >> Subject: Re: [aerogear-dev] wording change >> >> >> On 17/12/2014 17:40, Andres Galante wrote: >> > I've shared the new website at the UX team meeting today. >> > >> > They think think that we should change the word "features" to "solutions" or "components". >> >> I hate "solutions" with a passion, and "components" is not the right >> word. How about "modules" or "sub-projects" >> >> > >> > It seems that it is hard to understand that aerogear is actually 4 different products and the word "features" doesn't reflect that. >> > >> > What do you think? >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.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 > > -- > 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/20141219/d3cf2792/attachment-0001.html From bruno at abstractj.org Fri Dec 19 12:39:32 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 19 Dec 2014 15:39:32 -0200 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: <81204C25-6602-4972-8765-7F8B8867EC77@gmail.com> References: <81204C25-6602-4972-8765-7F8B8867EC77@gmail.com> Message-ID: I think due to holidays, Xmas and New Year's we don't need to rush on it. Let's postpone the release to next year. On Thu, Dec 18, 2014 at 6:25 PM, Corinne Krych wrote: > Hello iOS lovers, > > I?ve just found an issue with our aerogear-ios-http library [1] that we > think is a blocker for our 2.1 release planned on Friday. > > The problem occurs when using Http object as local variable rather than > instance variable, the root cause is the releasing of NSURLSession > happening too early. But the problem brought to our attention some code > confusion around the usage of the public API. We would like to fix the > issue with some serious refactor. > > Where to go from here? > After sitting down with Christos, we think a solid http ground is > essential to support our oauth2 lib, we?ve got some ideas on how we want to > refactor. This issue is our main priority and as soon as we?ve got a fix, > we?ll do the release. Christos is already working full time on this > refactor so we can deliver as soon as possible the next exciting version of > our libs. > > If you have any questions, concerns, this is the thread to ask. > > ++ > Corinne > [1] https://issues.jboss.org/browse/AGIOS-325 > > > On 16 Dec 2014, at 07:36, Christos Vasilakis wrote: > > > > Hi AeroGear community, > > > > we are happy to announce a pre-release of our various iOS libraries. > Here are few of new features introduced in each respective list: > > > > - aerogear-ios-jsonsz (new) > > A newly introduced library which will take care the cumbersome > plumbing required when performing JSON serialisation back and forth from > your Swift object model. For an example usage of the library together with > our http-lib check our Buddies cookbook example. > > > > - aerogear-ios-http > > We added the ability to perform basic/digest authentication when > performing REST Requests. Check out our Authentication cookbook example, > for an example usage of the API but remember to prefer HTTPS over plain > HTTP when performing authentication of this type. > > > > - aerogear-ios-oauth2 > > Continuing the development of our OAuth2 library, OpenID Connect > support was added to the library in the form of a ?login? request. Checkout > out our ?SharedShoot? cookbook example that login's to KeyCloak using > OpenID connect for an example usage. > > > > - aerogear-ios-httpstub > > Stubbed responses from the local file system can be used instead > of coding them in your code. This will make easier to stub responses, > especially big ones and be much ?closer? to the reality. Check out our > tests for an example usage. > > > > > > Last, this release introduces Cocoapod support for our libraries. > Although Cocoapods hasn?t yet officially support ?Swift? that is planned > for the next 0.36 release, a branch on the project is working on it and > already libraries starting to adopt. Just make sure to include a Gemfile in > your project pointing to that cocoapods branch (see here for more detailed > instructions) and in your Podfile include the desired library. For example > usage, see our cookbook repository where all of our demos have been > converted. > > > > So, give the libraries and demos a spin and let us know what you think. > If no bad things heard we are planning to tag and officially release 2.1 > this Friday. > > > > Have fun! > > > > Corinne & Christos > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141219/14184681/attachment.html From daniel.bevenius at gmail.com Fri Dec 19 13:39:00 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 19 Dec 2014 19:39:00 +0100 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: References: <81204C25-6602-4972-8765-7F8B8867EC77@gmail.com> Message-ID: +1 Better to take time and not rush it. fredag 19 december 2014 skrev Bruno Oliveira : > I think due to holidays, Xmas and New Year's we don't need to rush on it. > Let's postpone the release to next year. > > On Thu, Dec 18, 2014 at 6:25 PM, Corinne Krych > wrote: > >> Hello iOS lovers, >> >> I?ve just found an issue with our aerogear-ios-http library [1] that we >> think is a blocker for our 2.1 release planned on Friday. >> >> The problem occurs when using Http object as local variable rather than >> instance variable, the root cause is the releasing of NSURLSession >> happening too early. But the problem brought to our attention some code >> confusion around the usage of the public API. We would like to fix the >> issue with some serious refactor. >> >> Where to go from here? >> After sitting down with Christos, we think a solid http ground is >> essential to support our oauth2 lib, we?ve got some ideas on how we want to >> refactor. This issue is our main priority and as soon as we?ve got a fix, >> we?ll do the release. Christos is already working full time on this >> refactor so we can deliver as soon as possible the next exciting version of >> our libs. >> >> If you have any questions, concerns, this is the thread to ask. >> >> ++ >> Corinne >> [1] https://issues.jboss.org/browse/AGIOS-325 >> >> > On 16 Dec 2014, at 07:36, Christos Vasilakis > > wrote: >> > >> > Hi AeroGear community, >> > >> > we are happy to announce a pre-release of our various iOS libraries. >> Here are few of new features introduced in each respective list: >> > >> > - aerogear-ios-jsonsz (new) >> > A newly introduced library which will take care the cumbersome >> plumbing required when performing JSON serialisation back and forth from >> your Swift object model. For an example usage of the library together with >> our http-lib check our Buddies cookbook example. >> > >> > - aerogear-ios-http >> > We added the ability to perform basic/digest authentication when >> performing REST Requests. Check out our Authentication cookbook example, >> for an example usage of the API but remember to prefer HTTPS over plain >> HTTP when performing authentication of this type. >> > >> > - aerogear-ios-oauth2 >> > Continuing the development of our OAuth2 library, OpenID Connect >> support was added to the library in the form of a ?login? request. Checkout >> out our ?SharedShoot? cookbook example that login's to KeyCloak using >> OpenID connect for an example usage. >> > >> > - aerogear-ios-httpstub >> > Stubbed responses from the local file system can be used instead >> of coding them in your code. This will make easier to stub responses, >> especially big ones and be much ?closer? to the reality. Check out our >> tests for an example usage. >> > >> > >> > Last, this release introduces Cocoapod support for our libraries. >> Although Cocoapods hasn?t yet officially support ?Swift? that is planned >> for the next 0.36 release, a branch on the project is working on it and >> already libraries starting to adopt. Just make sure to include a Gemfile in >> your project pointing to that cocoapods branch (see here for more detailed >> instructions) and in your Podfile include the desired library. For example >> usage, see our cookbook repository where all of our demos have been >> converted. >> > >> > So, give the libraries and demos a spin and let us know what you >> think. If no bad things heard we are planning to tag and officially release >> 2.1 this Friday. >> > >> > Have fun! >> > >> > Corinne & Christos >> > >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141219/3c9d2ae2/attachment.html From rajnukala at yahoo.com Fri Dec 19 22:56:08 2014 From: rajnukala at yahoo.com (Raj Nukala) Date: Sat, 20 Dec 2014 03:56:08 +0000 (UTC) Subject: [aerogear-dev] Forgot admin password , how to to reset it Message-ID: <298573909.927590.1419047768675.JavaMail.yahoo@jws100168.mail.ne1.yahoo.com> I tried google and could not find the answer . How can I reset the admin password for aerogear unified push server Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141220/290631e4/attachment.html From rajnukala at yahoo.com Sat Dec 20 12:42:13 2014 From: rajnukala at yahoo.com (Raj Nukala) Date: Sat, 20 Dec 2014 17:42:13 +0000 (UTC) Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: Message-ID: <791508465.52269.1419097333413.JavaMail.yahoo@jws10001g.mail.ne1.yahoo.com> This is great . I missed the screencast is there a recording somewhere? For my project i need geofencing features and if only this is well documented and there is a binary i would love to use it . RegardsRaj From: Matthias Wessendorf To: AeroGear Developer Mailing List Sent: Tuesday, December 16, 2014 12:13 AM Subject: Re: [aerogear-dev] [POC] Unified Geo Server On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira wrote: On 2014-12-15, Matthias Wessendorf wrote: > On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira wrote: > > > > Good morning, first nice screencast Sebi and even knowing this is just a > > PoC I have some considerations: > > > > 1. What would be the use case scenario to justify a separated server > > instead of just a module on AGPUSH? > > > > I think main discussion around this at F2F meeting was, it might be useful > for other scenarios as well, > and we don't want to hard-wire geo to the push server Which scenarios? anything else that may require geo data. E.g. other systems may benefit from interacting with geo as well.I really do not see a reason why geo is hard-wired to push. the geo server should be a system to store any sorts of geo data (long/lat) + some APIs to query.? ? > > > > > > > 2. How do you plan to prevent people from faking their location? > > > > I'd assume that a Geo SDK would be based on-top of the mobile OS's > facility, to receive the long/lat values. > I think in the future we can have some sort of checks, like validating the > users IP address, if it somewhat matches the submitted geo data. I think Geo based on IPs are a bad idea. This is a very inaccurate method and should be our last resort, it's easy to spoof IPs. :-) yeah. I'd assume that we offer minimal/simple SDKs for iOS/Android, which underneathleverage the OS facilities for Geo-Data. Like CoreLocation on iOS. Regarding the IP, I had this in mind (not sure if that is a good idea or not):* if long/lat (can be faked with man-in-the-middle) says Germany, but IP says singapore,our server could see: something is wrong. or if we get weird long/lats from the same device (.e.g. 12:00 Germany, 12:30 UK, 14:00 USA, 14:30 China),we might know something is wrong too. But that's perhaps not for the initial scope of the poc > > > > > > > 3. Do we have a privacy policy to make the developer real aware about > > what's being collected? > > > > I think that the level of collected geo data is up to the developer of the > app, using the Geo SDK. I'm sorry, but I have to disagree. If we don't provide a policy about the usage of the Geo server, we're pretty much accountable for it. Nothing huge, only a simple txt documenting what's being collected and why. I'd think that, if we provide an SDK (and the POC will get us there), we do not really track anything 'silently'.I hope that the SDK would allow me to get the current position (e.g. using CoreLocation), and store it with a name (e.g. home, work, my fav. cinema) and some metadata (e.g. username). But I'd not imagine our SDK constantly tracks all positions and silently sends them to the Geo Server.? ? > > > > > > 4. Will collecting geo location be opt in or default? > > > > If the Geo-data SDK is used w/in an app, I think it will still ask, > up-front, if location based services are OK to use (at least apple). And > I'd argue that users can still disable the geo usage, per app (at least > apple) Most of users have no idea that their data is being collected. I'm confused about your answer, is that an yes or no? I mean yes, see above.? -MAtthias > > > > > > > > 5. Why is necessary to store current user's position? > > > I think that's up to the use case, and its usage of the Geo SDK. Currently we store. I know this is just a proof of concept. But I insist to be the boring, and avoid it if possible. > > > > Couldn't admin > > specify a range and check how many devices are active on that region? > > Into this way you don't need to store their positions. I'm not the Geo > > specialist here but the idea is: > > > > 1. Admin specify the range when a push message must be sent. For > > example: Whole Florida > > 2. Client opt in and sent her its position to the server > > 3. Server compares and sent the push message > > > > I'm very concerned about privacy here, I'm not against the > > solution, but Geo location is like to open a Pandora box. > > > > yeah, it's also creepy :) I have not much services that I give my geo data > > > > > > We might be careful about unintentional disclosure of geolocation > > information, > > because it carries physical risks to the client (theft, to stalking, > > kidnapping > > and domestic violence ? I'm not exaggerating). > > > > +1 I'd argue that the "Geo server" would be, initially, a 'simple' back > end, that is able to store n pairs of long/lat values (grouped by a > user/device). > The mobile SDK for it basically store the 'collected' data to this backend > (somewhat similar to the push registration SDK) > > > > > > Again, I know this is a proof of concept, but sooner we have it in mind, > > the > > better. > > > > +1 fully agree. Replied to your questions with my POV on this > > > > > > > > > > > > > On 2014-12-10, Sebastien Blanc wrote: > > > Hi all, > > > > > > I have been working on a POC around geolocation. Like we discussed in > > > another thread, we decided not to have a "deep" integration with the Push > > > server but instead a separate component / microservice. Well the POC is > > > more a miniservice ;) > > > > > > So, the idea is to have a server to which devices can register by > > providing > > > their positions. On the other side, the server provide an endpoint to > > make > > > spatial queries, like give me all the installations within a radius of 10 > > > km around this lat/ltg. > > > > > > Thanks to Forge, I created/scaffolded a really simple server providing > > the > > > registration endpoint and the search endpoint. > > > > > > I tried to make a decent readme that will give you more details : > > > > > > https://github.com/sebastienblanc/unified-geo-server > > > > > > And as usual, I made a little screencast showing all that in action ;) > > > > > > https://www.youtube.com/watch?v=R-qdLJh4EWQ > > > > > > Please remember this is a POC, so the security is almost inexistant, the > > > console is awful ;) > > > > > > What about the Client SDKs ? > > > > > > If we reach some kind of consensus arounf the concept of Unfied Geo > > Server > > > we can start building the Client SDKs / POCs , they will be quite simple > > : > > > retrieve geolocation and register to the geo endpoint. > > > > > > Sebi > > > > > _______________________________________________ > > > 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 -- 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/20141220/bcda800e/attachment-0001.html From rajnukala at yahoo.com Sat Dec 20 15:00:37 2014 From: rajnukala at yahoo.com (Raj Nukala) Date: Sat, 20 Dec 2014 20:00:37 +0000 (UTC) Subject: [aerogear-dev] [POC] Unified Geo Server In-Reply-To: References: Message-ID: <1630913627.1022215.1419105637581.JavaMail.yahoo@jws100210.mail.ne1.yahoo.com> Great work sebi . How frequently are the lat longs sent to the geo server?? and what is the backend db for the geo server ? is it mongo ? Regards From: Sebastien Blanc To: AeroGear Developer Mailing List Sent: Monday, December 15, 2014 6:10 PM Subject: Re: [aerogear-dev] [POC] Unified Geo Server On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira wrote: On 2014-12-15, Matthias Wessendorf wrote: > On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira wrote: > > > > Good morning, first nice screencast Sebi and even knowing this is just a > > PoC I have some considerations: > > > > 1. What would be the use case scenario to justify a separated server > > instead of just a module on AGPUSH? > > > > I think main discussion around this at F2F meeting was, it might be useful > for other scenarios as well, > and we don't want to hard-wire geo to the push server Which scenarios? The are several scenarios where geo is needed without push.?For instance, think of a backend system for a transport company that needs to run analysis each night based on the current location of the truck drivers in order to plan efficiently the logistics for the next day. ? > > > > > > > 2. How do you plan to prevent people from faking their location? > > > > I'd assume that a Geo SDK would be based on-top of the mobile OS's > facility, to receive the long/lat values. > I think in the future we can have some sort of checks, like validating the > users IP address, if it somewhat matches the submitted geo data. I think Geo based on IPs are a bad idea. This is a very inaccurate method and should be our last resort, it's easy to spoof IPs. > > > > > > > 3. Do we have a privacy policy to make the developer real aware about > > what's being collected? > > > > I think that the level of collected geo data is up to the developer of the > app, using the Geo SDK. I'm sorry, but I have to disagree. If we don't provide a policy about the usage of the Geo server, we're pretty much accountable for it. Nothing huge, only a simple txt documenting what's being collected and why. > > > > > > 4. Will collecting geo location be opt in or default? > > > > If the Geo-data SDK is used w/in an app, I think it will still ask, > up-front, if location based services are OK to use (at least apple). And > I'd argue that users can still disable the geo usage, per app (at least > apple) Most of users have no idea that their data is being collected. I'm confused about your answer, is that an yes or no? I think what Matthias means is that when using gelolocation on the device, being iOS, Android or even Web, the users will be prompted to allow or not access to his geodata. So, yes it's an opt-in and also, like Matthias said a the possibility to opt-out.? > > > > > > > > 5. Why is necessary to store current user's position? > > > I think that's up to the use case, and its usage of the Geo SDK. Currently we store. I know this is just a proof of concept. But I insist to be the boring, and avoid it if possible. If we don't store we can not make geo queries. Without these queries the question of having a geo server is quite useless ... But we could think of a "flavor" or variant ;) ?where the geo data is not persisted but just ?pass through (to a queue, another REST endpoint), It will more act then like a broker, but again not sure if I can find a usecase for that. > > > > Couldn't admin > > specify a range and check how many devices are active on that region? > > Into this way you don't need to store their positions. I'm not the Geo > > specialist here but the idea is: > > > > 1. Admin specify the range when a push message must be sent. For > > example: Whole Florida > > 2. Client opt in and sent her its position to the server > > 3. Server compares and sent the push message > > > > I'm very concerned about privacy here, I'm not against the > > solution, but Geo location is like to open a Pandora box. > > > > yeah, it's also creepy :) I have not much services that I give my geo data > > > > > > We might be careful about unintentional disclosure of geolocation > > information, > > because it carries physical risks to the client (theft, to stalking, > > kidnapping > > and domestic violence ? I'm not exaggerating). > > > > +1 I'd argue that the "Geo server" would be, initially, a 'simple' back > end, that is able to store n pairs of long/lat values (grouped by a > user/device). > The mobile SDK for it basically store the 'collected' data to this backend > (somewhat similar to the push registration SDK) > > > > > > Again, I know this is a proof of concept, but sooner we have it in mind, > > the > > better. > > > > +1 fully agree. Replied to your questions with my POV on this > > > > > > > > > > > > > On 2014-12-10, Sebastien Blanc wrote: > > > Hi all, > > > > > > I have been working on a POC around geolocation. Like we discussed in > > > another thread, we decided not to have a "deep" integration with the Push > > > server but instead a separate component / microservice. Well the POC is > > > more a miniservice ;) > > > > > > So, the idea is to have a server to which devices can register by > > providing > > > their positions. On the other side, the server provide an endpoint to > > make > > > spatial queries, like give me all the installations within a radius of 10 > > > km around this lat/ltg. > > > > > > Thanks to Forge, I created/scaffolded a really simple server providing > > the > > > registration endpoint and the search endpoint. > > > > > > I tried to make a decent readme that will give you more details : > > > > > > https://github.com/sebastienblanc/unified-geo-server > > > > > > And as usual, I made a little screencast showing all that in action ;) > > > > > > https://www.youtube.com/watch?v=R-qdLJh4EWQ > > > > > > Please remember this is a POC, so the security is almost inexistant, the > > > console is awful ;) > > > > > > What about the Client SDKs ? > > > > > > If we reach some kind of consensus arounf the concept of Unfied Geo > > Server > > > we can start building the Client SDKs / POCs , they will be quite simple > > : > > > retrieve geolocation and register to the geo endpoint. > > > > > > Sebi > > > > > _______________________________________________ > > > 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 -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141220/f1864f6e/attachment.html From corinnekrych at gmail.com Mon Dec 22 03:39:33 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 22 Dec 2014 09:39:33 +0100 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: References: <81204C25-6602-4972-8765-7F8B8867EC77@gmail.com> Message-ID: <56D7BFAF-44D6-416B-BD7D-DC8CBE7B2FA4@gmail.com> +1 with xmas holidays, a release might be tricky, let?s discuss release readiness on next iOS meeting Tuesday 6th December. ++ Corinne > On 19 Dec 2014, at 19:39, Daniel Bevenius wrote: > > +1 Better to take time and not rush it. > > fredag 19 december 2014 skrev Bruno Oliveira : > I think due to holidays, Xmas and New Year's we don't need to rush on it. Let's postpone the release to next year. > > On Thu, Dec 18, 2014 at 6:25 PM, Corinne Krych wrote: > Hello iOS lovers, > > I?ve just found an issue with our aerogear-ios-http library [1] that we think is a blocker for our 2.1 release planned on Friday. > > The problem occurs when using Http object as local variable rather than instance variable, the root cause is the releasing of NSURLSession happening too early. But the problem brought to our attention some code confusion around the usage of the public API. We would like to fix the issue with some serious refactor. > > Where to go from here? > After sitting down with Christos, we think a solid http ground is essential to support our oauth2 lib, we?ve got some ideas on how we want to refactor. This issue is our main priority and as soon as we?ve got a fix, we?ll do the release. Christos is already working full time on this refactor so we can deliver as soon as possible the next exciting version of our libs. > > If you have any questions, concerns, this is the thread to ask. > > ++ > Corinne > [1] https://issues.jboss.org/browse/AGIOS-325 > > > On 16 Dec 2014, at 07:36, Christos Vasilakis wrote: > > > > Hi AeroGear community, > > > > we are happy to announce a pre-release of our various iOS libraries. Here are few of new features introduced in each respective list: > > > > - aerogear-ios-jsonsz (new) > > A newly introduced library which will take care the cumbersome plumbing required when performing JSON serialisation back and forth from your Swift object model. For an example usage of the library together with our http-lib check our Buddies cookbook example. > > > > - aerogear-ios-http > > We added the ability to perform basic/digest authentication when performing REST Requests. Check out our Authentication cookbook example, for an example usage of the API but remember to prefer HTTPS over plain HTTP when performing authentication of this type. > > > > - aerogear-ios-oauth2 > > Continuing the development of our OAuth2 library, OpenID Connect support was added to the library in the form of a ?login? request. Checkout out our ?SharedShoot? cookbook example that login's to KeyCloak using OpenID connect for an example usage. > > > > - aerogear-ios-httpstub > > Stubbed responses from the local file system can be used instead of coding them in your code. This will make easier to stub responses, especially big ones and be much ?closer? to the reality. Check out our tests for an example usage. > > > > > > Last, this release introduces Cocoapod support for our libraries. Although Cocoapods hasn?t yet officially support ?Swift? that is planned for the next 0.36 release, a branch on the project is working on it and already libraries starting to adopt. Just make sure to include a Gemfile in your project pointing to that cocoapods branch (see here for more detailed instructions) and in your Podfile include the desired library. For example usage, see our cookbook repository where all of our demos have been converted. > > > > So, give the libraries and demos a spin and let us know what you think. If no bad things heard we are planning to tag and officially release 2.1 this Friday. > > > > Have fun! > > > > Corinne & Christos > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Mon Dec 22 03:46:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 22 Dec 2014 09:46:55 +0100 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: References: <81204C25-6602-4972-8765-7F8B8867EC77@gmail.com> Message-ID: On Fri, Dec 19, 2014 at 6:39 PM, Bruno Oliveira wrote: > I think due to holidays, Xmas and New Year's we don't need to rush on it. > Let's postpone the release to next year. > +1 > > On Thu, Dec 18, 2014 at 6:25 PM, Corinne Krych > wrote: > >> Hello iOS lovers, >> >> I?ve just found an issue with our aerogear-ios-http library [1] that we >> think is a blocker for our 2.1 release planned on Friday. >> >> The problem occurs when using Http object as local variable rather than >> instance variable, the root cause is the releasing of NSURLSession >> happening too early. But the problem brought to our attention some code >> confusion around the usage of the public API. We would like to fix the >> issue with some serious refactor. >> >> Where to go from here? >> After sitting down with Christos, we think a solid http ground is >> essential to support our oauth2 lib, we?ve got some ideas on how we want to >> refactor. This issue is our main priority and as soon as we?ve got a fix, >> we?ll do the release. Christos is already working full time on this >> refactor so we can deliver as soon as possible the next exciting version of >> our libs. >> >> If you have any questions, concerns, this is the thread to ask. >> >> ++ >> Corinne >> [1] https://issues.jboss.org/browse/AGIOS-325 >> >> > On 16 Dec 2014, at 07:36, Christos Vasilakis >> wrote: >> > >> > Hi AeroGear community, >> > >> > we are happy to announce a pre-release of our various iOS libraries. >> Here are few of new features introduced in each respective list: >> > >> > - aerogear-ios-jsonsz (new) >> > A newly introduced library which will take care the cumbersome >> plumbing required when performing JSON serialisation back and forth from >> your Swift object model. For an example usage of the library together with >> our http-lib check our Buddies cookbook example. >> > >> > - aerogear-ios-http >> > We added the ability to perform basic/digest authentication when >> performing REST Requests. Check out our Authentication cookbook example, >> for an example usage of the API but remember to prefer HTTPS over plain >> HTTP when performing authentication of this type. >> > >> > - aerogear-ios-oauth2 >> > Continuing the development of our OAuth2 library, OpenID Connect >> support was added to the library in the form of a ?login? request. Checkout >> out our ?SharedShoot? cookbook example that login's to KeyCloak using >> OpenID connect for an example usage. >> > >> > - aerogear-ios-httpstub >> > Stubbed responses from the local file system can be used instead >> of coding them in your code. This will make easier to stub responses, >> especially big ones and be much ?closer? to the reality. Check out our >> tests for an example usage. >> > >> > >> > Last, this release introduces Cocoapod support for our libraries. >> Although Cocoapods hasn?t yet officially support ?Swift? that is planned >> for the next 0.36 release, a branch on the project is working on it and >> already libraries starting to adopt. Just make sure to include a Gemfile in >> your project pointing to that cocoapods branch (see here for more detailed >> instructions) and in your Podfile include the desired library. For example >> usage, see our cookbook repository where all of our demos have been >> converted. >> > >> > So, give the libraries and demos a spin and let us know what you >> think. If no bad things heard we are planning to tag and officially release >> 2.1 this Friday. >> > >> > Have fun! >> > >> > Corinne & Christos >> > >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.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/20141222/32029b0a/attachment.html From bruno at abstractj.com Mon Dec 22 08:17:55 2014 From: bruno at abstractj.com (Bruno Oliveira) Date: Mon, 22 Dec 2014 05:17:55 -0800 (PST) Subject: [aerogear-dev] [Canceled] - AeroGear team meeting Message-ID: <1419254274759.be0791d4@Nodemailer> Good morning, due to holidays and the low number of attendees. All the meetings are canceled until next year. If you have questions, let us know. ? abstractj PGP: 0x84DC9914 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141222/78c93a53/attachment.html From lholmqui at redhat.com Mon Dec 22 08:27:02 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 22 Dec 2014 08:27:02 -0500 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: <56D7BFAF-44D6-416B-BD7D-DC8CBE7B2FA4@gmail.com> References: <81204C25-6602-4972-8765-7F8B8867EC77@gmail.com> <56D7BFAF-44D6-416B-BD7D-DC8CBE7B2FA4@gmail.com> Message-ID: <7B47EBC5-C0E7-4B00-8F38-15BAF00FA2CA@redhat.com> > On Dec 22, 2014, at 3:39 AM, Corinne Krych wrote: > > +1 with xmas holidays, a release might be tricky, let?s discuss release > readiness on next iOS meeting Tuesday 6th December. /me hops in time machine > > ++ > Corinne >> On 19 Dec 2014, at 19:39, Daniel Bevenius wrote: >> >> +1 Better to take time and not rush it. >> >> fredag 19 december 2014 skrev Bruno Oliveira : >> I think due to holidays, Xmas and New Year's we don't need to rush on it. Let's postpone the release to next year. >> >> On Thu, Dec 18, 2014 at 6:25 PM, Corinne Krych wrote: >> Hello iOS lovers, >> >> I?ve just found an issue with our aerogear-ios-http library [1] that we think is a blocker for our 2.1 release planned on Friday. >> >> The problem occurs when using Http object as local variable rather than instance variable, the root cause is the releasing of NSURLSession happening too early. But the problem brought to our attention some code confusion around the usage of the public API. We would like to fix the issue with some serious refactor. >> >> Where to go from here? >> After sitting down with Christos, we think a solid http ground is essential to support our oauth2 lib, we?ve got some ideas on how we want to refactor. This issue is our main priority and as soon as we?ve got a fix, we?ll do the release. Christos is already working full time on this refactor so we can deliver as soon as possible the next exciting version of our libs. >> >> If you have any questions, concerns, this is the thread to ask. >> >> ++ >> Corinne >> [1] https://issues.jboss.org/browse/AGIOS-325 >> >>> On 16 Dec 2014, at 07:36, Christos Vasilakis wrote: >>> >>> Hi AeroGear community, >>> >>> we are happy to announce a pre-release of our various iOS libraries. Here are few of new features introduced in each respective list: >>> >>> - aerogear-ios-jsonsz (new) >>> A newly introduced library which will take care the cumbersome plumbing required when performing JSON serialisation back and forth from your Swift object model. For an example usage of the library together with our http-lib check our Buddies cookbook example. >>> >>> - aerogear-ios-http >>> We added the ability to perform basic/digest authentication when performing REST Requests. Check out our Authentication cookbook example, for an example usage of the API but remember to prefer HTTPS over plain HTTP when performing authentication of this type. >>> >>> - aerogear-ios-oauth2 >>> Continuing the development of our OAuth2 library, OpenID Connect support was added to the library in the form of a ?login? request. Checkout out our ?SharedShoot? cookbook example that login's to KeyCloak using OpenID connect for an example usage. >>> >>> - aerogear-ios-httpstub >>> Stubbed responses from the local file system can be used instead of coding them in your code. This will make easier to stub responses, especially big ones and be much ?closer? to the reality. Check out our tests for an example usage. >>> >>> >>> Last, this release introduces Cocoapod support for our libraries. Although Cocoapods hasn?t yet officially support ?Swift? that is planned for the next 0.36 release, a branch on the project is working on it and already libraries starting to adopt. Just make sure to include a Gemfile in your project pointing to that cocoapods branch (see here for more detailed instructions) and in your Podfile include the desired library. For example usage, see our cookbook repository where all of our demos have been converted. >>> >>> So, give the libraries and demos a spin and let us know what you think. If no bad things heard we are planning to tag and officially release 2.1 this Friday. >>> >>> Have fun! >>> >>> Corinne & Christos >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> >> -- >> "The measure of a man is what he does with power" - Plato >> - >> @abstractj >> - >> Volenti Nihil Difficile >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.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 Mon Dec 22 14:03:53 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 22 Dec 2014 20:03:53 +0100 Subject: [aerogear-dev] Pre-release announcement of iOS libraries In-Reply-To: <7B47EBC5-C0E7-4B00-8F38-15BAF00FA2CA@redhat.com> References: <81204C25-6602-4972-8765-7F8B8867EC77@gmail.com> <56D7BFAF-44D6-416B-BD7D-DC8CBE7B2FA4@gmail.com> <7B47EBC5-C0E7-4B00-8F38-15BAF00FA2CA@redhat.com> Message-ID: On Monday, December 22, 2014, Lucas Holmquist wrote: > > > On Dec 22, 2014, at 3:39 AM, Corinne Krych > wrote: > > > > +1 with xmas holidays, a release might be tricky, let?s discuss release > > > readiness on next iOS meeting Tuesday 6th December. > /me hops in time machine > > I meant January 6th 2015 :) > > > ++ > > Corinne > >> On 19 Dec 2014, at 19:39, Daniel Bevenius > wrote: > >> > >> +1 Better to take time and not rush it. > >> > >> fredag 19 december 2014 skrev Bruno Oliveira >: > >> I think due to holidays, Xmas and New Year's we don't need to rush on > it. Let's postpone the release to next year. > >> > >> On Thu, Dec 18, 2014 at 6:25 PM, Corinne Krych > wrote: > >> Hello iOS lovers, > >> > >> I?ve just found an issue with our aerogear-ios-http library [1] that we > think is a blocker for our 2.1 release planned on Friday. > >> > >> The problem occurs when using Http object as local variable rather than > instance variable, the root cause is the releasing of NSURLSession > happening too early. But the problem brought to our attention some code > confusion around the usage of the public API. We would like to fix the > issue with some serious refactor. > >> > >> Where to go from here? > >> After sitting down with Christos, we think a solid http ground is > essential to support our oauth2 lib, we?ve got some ideas on how we want to > refactor. This issue is our main priority and as soon as we?ve got a fix, > we?ll do the release. Christos is already working full time on this > refactor so we can deliver as soon as possible the next exciting version of > our libs. > >> > >> If you have any questions, concerns, this is the thread to ask. > >> > >> ++ > >> Corinne > >> [1] https://issues.jboss.org/browse/AGIOS-325 > >> > >>> On 16 Dec 2014, at 07:36, Christos Vasilakis > wrote: > >>> > >>> Hi AeroGear community, > >>> > >>> we are happy to announce a pre-release of our various iOS libraries. > Here are few of new features introduced in each respective list: > >>> > >>> - aerogear-ios-jsonsz (new) > >>> A newly introduced library which will take care the cumbersome > plumbing required when performing JSON serialisation back and forth from > your Swift object model. For an example usage of the library together with > our http-lib check our Buddies cookbook example. > >>> > >>> - aerogear-ios-http > >>> We added the ability to perform basic/digest authentication when > performing REST Requests. Check out our Authentication cookbook example, > for an example usage of the API but remember to prefer HTTPS over plain > HTTP when performing authentication of this type. > >>> > >>> - aerogear-ios-oauth2 > >>> Continuing the development of our OAuth2 library, OpenID Connect > support was added to the library in the form of a ?login? request. Checkout > out our ?SharedShoot? cookbook example that login's to KeyCloak using > OpenID connect for an example usage. > >>> > >>> - aerogear-ios-httpstub > >>> Stubbed responses from the local file system can be used instead > of coding them in your code. This will make easier to stub responses, > especially big ones and be much ?closer? to the reality. Check out our > tests for an example usage. > >>> > >>> > >>> Last, this release introduces Cocoapod support for our libraries. > Although Cocoapods hasn?t yet officially support ?Swift? that is planned > for the next 0.36 release, a branch on the project is working on it and > already libraries starting to adopt. Just make sure to include a Gemfile in > your project pointing to that cocoapods branch (see here for more detailed > instructions) and in your Podfile include the desired library. For example > usage, see our cookbook repository where all of our demos have been > converted. > >>> > >>> So, give the libraries and demos a spin and let us know what you > think. If no bad things heard we are planning to tag and officially release > 2.1 this Friday. > >>> > >>> Have fun! > >>> > >>> Corinne & Christos > >>> > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> -- > >> > >> -- > >> "The measure of a man is what he does with power" - Plato > >> - > >> @abstractj > >> - > >> Volenti Nihil Difficile > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.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/20141222/89f50c27/attachment-0001.html From agalante at redhat.com Tue Dec 23 10:23:24 2014 From: agalante at redhat.com (Andres Galante) Date: Tue, 23 Dec 2014 10:23:24 -0500 (EST) Subject: [aerogear-dev] Aerogear.org redesign In-Reply-To: <800994770.178074.1419347793901.JavaMail.zimbra@redhat.com> Message-ID: <2008024913.178867.1419348204037.JavaMail.zimbra@redhat.com> Hi! I don't think there is much more I can do on the website by my own. I'll need your help to: - Write text and correct typos. There is text to write on Homepage, Modules (add more text for each module) and Guides, you'll notice the Lorem ipsum :) - Review the structure for Downloads, Guides and Specs - What logos to put on the homepage footer - Review styles and design. Did I forget to change anything that was requested? We can discuss this in january when everyone is back. For the ones that are around: Happy holidays :) Thanks! Andr?s From daniel at passos.me Tue Dec 23 17:35:18 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 23 Dec 2014 20:35:18 -0200 Subject: [aerogear-dev] Move OTP and Crypto demo to cookbook repo Message-ID: I was adding a list of non cookbook apps[1] on cookbook README and thinking. Should we move the OTP and Crypto demo to the cookbook repo? Wdyt? [1] https://github.com/aerogear/aerogear-android-cookbook/pull/29/ -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141223/3113114d/attachment.html From bruno at abstractj.org Tue Dec 23 18:11:17 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 23 Dec 2014 15:11:17 -0800 (PST) Subject: [aerogear-dev] Move OTP and Crypto demo to cookbook repo In-Reply-To: References: Message-ID: <1419376276657.446c5fc7@Nodemailer> Yes please! ? abstractj PGP: 0x84DC9914 On Tue, Dec 23, 2014 at 8:35 PM, Daniel Passos wrote: > I was adding a list of non cookbook apps[1] on cookbook README and > thinking. Should we move the OTP and Crypto demo to the cookbook repo? > Wdyt? > [1] https://github.com/aerogear/aerogear-android-cookbook/pull/29/ > -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141223/80d454c4/attachment.html From vivek.pandey at pinelabs.com Fri Dec 26 01:00:47 2014 From: vivek.pandey at pinelabs.com (Vivek Pandey) Date: Fri, 26 Dec 2014 11:30:47 +0530 Subject: [aerogear-dev] UPS : How to get notified when an installation is deleted/updated Message-ID: <004701d020d1$4b42ff40$e1c8fdc0$@pinelabs.com> Hello UPS team, Hope you had a wonderful Christmas!! I am using UPS 1.0.2 (on postgres/wildfly 8.1) and wanted to understand the best strategy to sync deletions of installation in UPS to my own db. My current implementation stores the push token in my own db and registers them to UPS periodically. However, currently I do not have any strategy to sync deletions to my own db. Does UPS publish deletion events? Or there is any bulk query mechanism to fetch a paginated list of active installations? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141226/0f887cb1/attachment.html