From florian.traverse at allocab.com  Thu Nov  5 05:30:22 2015
From: florian.traverse at allocab.com (Florian Traverse)
Date: Thu, 05 Nov 2015 10:30:22 +0000
Subject: [Aerogear-users] Handshake issue when connecting to APNS (from
	OpenShift Online)
Message-ID: <CAJ4FD9xMXaj4Qn6PTmPwp8u5wc-QpvFG1nqH613hFHjEfpgCEA@mail.gmail.com>

Hi all :)

We encounter an issue since yesterday on our aerogear server running in
production for several months on OpenShift Online (
OPENSHIFT_AEROGEAR_PUSH_VERSION=1.0.3 ) :

Management interface would report the handshake error as well, and none of
all our iOS pushes, whatever the `application`, whatever the `variant`,
would work.

We're looking for what can go wrong in order to fix it. We still have both
RAM and disk available, and a `gear restart` would not help in the matter.

Here's what the stacktrace looks like in the logs, can anybody help ?

```
ERROR [com.notnoop.apns.internal.ApnsConnectionImpl] (EJB default - 4)
Couldn't send message after 3 retries.Message(Id=1; Token=<TOKEN>;
Payload={"<some_payload_property>":"<some numeric
value>","aps":{"alert":"<The notification text>","badge":-1}}):
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: No trusted certificate found
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
[jsse.jar:1.7.0_85]
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1916)
[jsse.jar:1.7.0_85]
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:279)
[jsse.jar:1.7.0_85]
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:273)
[jsse.jar:1.7.0_85]
    at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1469)
[jsse.jar:1.7.0_85]
    at
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:213)
[jsse.jar:1.7.0_85]
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:913)
[jsse.jar:1.7.0_85]
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:849)
[jsse.jar:1.7.0_85]
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1035)
[jsse.jar:1.7.0_85]
    at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
[jsse.jar:1.7.0_85]
    at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:721)
[jsse.jar:1.7.0_85]
    at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
[jsse.jar:1.7.0_85]
    at java.io.OutputStream.write(OutputStream.java:75) [rt.jar:1.7.0_85]
    at
com.notnoop.apns.internal.ApnsConnectionImpl.sendMessage(ApnsConnectionImpl.java:322)
[apns-1.0.0.Beta5.jar:]
    at
com.notnoop.apns.internal.ApnsConnectionImpl.sendMessage(ApnsConnectionImpl.java:310)
[apns-1.0.0.Beta5.jar:]
    at
com.notnoop.apns.internal.ApnsServiceImpl.push(ApnsServiceImpl.java:46)
[apns-1.0.0.Beta5.jar:]
    at
com.notnoop.apns.internal.AbstractApnsService.push(AbstractApnsService.java:102)
[apns-1.0.0.Beta5.jar:]
    at
com.notnoop.apns.internal.ApnsServiceImpl.push(ApnsServiceImpl.java:36)
[apns-1.0.0.Beta5.jar:]
    at
org.jboss.aerogear.unifiedpush.message.sender.APNsPushNotificationSender.sendPushMessage(APNsPushNotificationSender.java:109)
[unifiedpush-push-1.0.3.jar:1.0.3]
    at
org.jboss.aerogear.unifiedpush.message.SenderServiceImpl.send(SenderServiceImpl.java:116)
[unifiedpush-push-1.0.3.jar:1.0.3]
    at sun.reflect.GeneratedMethodAccessor149.invoke(Unknown Source)
[:1.7.0_85]
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_85]
    at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_85]
    at
org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
    at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
    at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
[wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
[wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
    at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
[wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
    at
org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
[weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
    at
org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
[wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
[wildfly-ee-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
    at
org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
    at
org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
    at
org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
    at
org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
    at
org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
    at
org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:79)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at
org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
[wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_85]
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_85]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_85]
    at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: sun.security.validator.ValidatorException: No trusted
certificate found
    at
sun.security.validator.SimpleValidator.buildTrustedChain(SimpleValidator.java:394)
[rt.jar:1.7.0_85]
    at
sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:134)
[rt.jar:1.7.0_85]
    at sun.security.validator.Validator.validate(Validator.java:260)
[rt.jar:1.7.0_85]
    at
sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
[jsse.jar:1.7.0_85]
    at
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
[jsse.jar:1.7.0_85]
    at
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
[jsse.jar:1.7.0_85]
    at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1451)
[jsse.jar:1.7.0_85]
    ... 87 more

2015-11-05 04:32:39,596 WARNING [APNsPushNotificationSender] (EJB default -
4) Error on &apos;ios&apos; delivery
2015-11-05 04:40:00,169 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-26)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:21,553 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-30)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:26,675 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-33)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:28,864 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-34)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:30,969 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-37)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:33,150 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-36)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:36,375 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-39)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:43,324 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-43)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:46,273 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-41)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:48,448 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-40)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:50,514 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-42)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:52,733 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-45)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:55,093 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-46)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:56,742 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-44)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:40:58,947 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-51)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:41:01,469 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-50)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:41:03,297 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-52)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
2015-11-05 04:41:09,376 WARN
[org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-55)
HHH000104: firstResult/maxResults specified with collection fetch; applying
in memory!
-- 
Florian TRAVERSE
Software Architect

Allocab, votre chauffeur sur-mesure
M. +33 6 12 39 66 50
A. 7 impasse Charles Petit, 75011 Paris
W. www.allocab.com
E. florian.traverse at allocab.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151105/d1d31ee9/attachment-0001.html 

From matzew at apache.org  Thu Nov  5 09:54:12 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 5 Nov 2015 15:54:12 +0100
Subject: [Aerogear-users] Handshake issue when connecting to APNS (from
 OpenShift Online)
In-Reply-To: <CAJ4FD9xMXaj4Qn6PTmPwp8u5wc-QpvFG1nqH613hFHjEfpgCEA@mail.gmail.com>
References: <CAJ4FD9xMXaj4Qn6PTmPwp8u5wc-QpvFG1nqH613hFHjEfpgCEA@mail.gmail.com>
Message-ID: <CAAg5f2SJqQZAa=fp4BH-RYU55OVJFigLqj06Kj+zZ+rjvy-HCw@mail.gmail.com>

A problem w/ your certificate? Is that still valid ?

On Thu, Nov 5, 2015 at 11:30 AM, Florian Traverse <
florian.traverse at allocab.com> wrote:

> Hi all :)
>
> We encounter an issue since yesterday on our aerogear server running in
> production for several months on OpenShift Online (
> OPENSHIFT_AEROGEAR_PUSH_VERSION=1.0.3 ) :
>
> Management interface would report the handshake error as well, and none of
> all our iOS pushes, whatever the `application`, whatever the `variant`,
> would work.
>
> We're looking for what can go wrong in order to fix it. We still have both
> RAM and disk available, and a `gear restart` would not help in the matter.
>
> Here's what the stacktrace looks like in the logs, can anybody help ?
>
> ```
> ERROR [com.notnoop.apns.internal.ApnsConnectionImpl] (EJB default - 4)
> Couldn't send message after 3 retries.Message(Id=1; Token=<TOKEN>;
> Payload={"<some_payload_property>":"<some numeric
> value>","aps":{"alert":"<The notification text>","badge":-1}}):
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: No trusted certificate found
>     at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> [jsse.jar:1.7.0_85]
>     at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1916)
> [jsse.jar:1.7.0_85]
>     at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:279)
> [jsse.jar:1.7.0_85]
>     at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:273)
> [jsse.jar:1.7.0_85]
>     at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1469)
> [jsse.jar:1.7.0_85]
>     at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:213)
> [jsse.jar:1.7.0_85]
>     at sun.security.ssl.Handshaker.processLoop(Handshaker.java:913)
> [jsse.jar:1.7.0_85]
>     at sun.security.ssl.Handshaker.process_record(Handshaker.java:849)
> [jsse.jar:1.7.0_85]
>     at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1035)
> [jsse.jar:1.7.0_85]
>     at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
> [jsse.jar:1.7.0_85]
>     at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:721)
> [jsse.jar:1.7.0_85]
>     at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
> [jsse.jar:1.7.0_85]
>     at java.io.OutputStream.write(OutputStream.java:75) [rt.jar:1.7.0_85]
>     at
> com.notnoop.apns.internal.ApnsConnectionImpl.sendMessage(ApnsConnectionImpl.java:322)
> [apns-1.0.0.Beta5.jar:]
>     at
> com.notnoop.apns.internal.ApnsConnectionImpl.sendMessage(ApnsConnectionImpl.java:310)
> [apns-1.0.0.Beta5.jar:]
>     at
> com.notnoop.apns.internal.ApnsServiceImpl.push(ApnsServiceImpl.java:46)
> [apns-1.0.0.Beta5.jar:]
>     at
> com.notnoop.apns.internal.AbstractApnsService.push(AbstractApnsService.java:102)
> [apns-1.0.0.Beta5.jar:]
>     at
> com.notnoop.apns.internal.ApnsServiceImpl.push(ApnsServiceImpl.java:36)
> [apns-1.0.0.Beta5.jar:]
>     at
> org.jboss.aerogear.unifiedpush.message.sender.APNsPushNotificationSender.sendPushMessage(APNsPushNotificationSender.java:109)
> [unifiedpush-push-1.0.3.jar:1.0.3]
>     at
> org.jboss.aerogear.unifiedpush.message.SenderServiceImpl.send(SenderServiceImpl.java:116)
> [unifiedpush-push-1.0.3.jar:1.0.3]
>     at sun.reflect.GeneratedMethodAccessor149.invoke(Unknown Source)
> [:1.7.0_85]
>     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_85]
>     at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_85]
>     at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
>     at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
>     at
> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
> [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at
> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> [wildfly-ee-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at
> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at
> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at
> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at
> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at
> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at
> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:79)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at
> org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [rt.jar:1.7.0_85]
>     at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [rt.jar:1.7.0_85]
>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_85]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: sun.security.validator.ValidatorException: No trusted
> certificate found
>     at
> sun.security.validator.SimpleValidator.buildTrustedChain(SimpleValidator.java:394)
> [rt.jar:1.7.0_85]
>     at
> sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:134)
> [rt.jar:1.7.0_85]
>     at sun.security.validator.Validator.validate(Validator.java:260)
> [rt.jar:1.7.0_85]
>     at
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
> [jsse.jar:1.7.0_85]
>     at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
> [jsse.jar:1.7.0_85]
>     at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
> [jsse.jar:1.7.0_85]
>     at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1451)
> [jsse.jar:1.7.0_85]
>     ... 87 more
>
> 2015-11-05 04:32:39,596 WARNING [APNsPushNotificationSender] (EJB default
> - 4) Error on &apos;ios&apos; delivery
> 2015-11-05 04:40:00,169 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-26)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:21,553 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-30)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:26,675 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-33)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:28,864 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-34)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:30,969 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-37)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:33,150 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-36)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:36,375 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-39)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:43,324 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-43)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:46,273 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-41)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:48,448 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-40)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:50,514 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-42)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:52,733 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-45)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:55,093 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-46)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:56,742 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-44)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:40:58,947 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-51)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:41:01,469 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-50)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:41:03,297 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-52)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> 2015-11-05 04:41:09,376 WARN
> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-55)
> HHH000104: firstResult/maxResults specified with collection fetch; applying
> in memory!
> --
> Florian TRAVERSE
> Software Architect
>
> Allocab, votre chauffeur sur-mesure
> M. +33 6 12 39 66 50
> A. 7 impasse Charles Petit, 75011 Paris
> W. www.allocab.com
> E. florian.traverse at allocab.com
>
> _______________________________________________
> 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-users/attachments/20151105/1ceed308/attachment-0001.html 

From matzew at apache.org  Thu Nov  5 10:31:33 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 5 Nov 2015 16:31:33 +0100
Subject: [Aerogear-users] Handshake issue when connecting to APNS (from
 OpenShift Online)
In-Reply-To: <CAAg5f2SJqQZAa=fp4BH-RYU55OVJFigLqj06Kj+zZ+rjvy-HCw@mail.gmail.com>
References: <CAJ4FD9xMXaj4Qn6PTmPwp8u5wc-QpvFG1nqH613hFHjEfpgCEA@mail.gmail.com>
	<CAAg5f2SJqQZAa=fp4BH-RYU55OVJFigLqj06Kj+zZ+rjvy-HCw@mail.gmail.com>
Message-ID: <CAAg5f2Ratmy9fOHuXnhUiDYDmPiwopuMzMWTZzqtTtbzPkCJ_g@mail.gmail.com>

Florian,

I just tried (but I had to create a new cert - since all my dev certs
expired last month), and it works for me

On Thu, Nov 5, 2015 at 3:54 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> A problem w/ your certificate? Is that still valid ?
>
> On Thu, Nov 5, 2015 at 11:30 AM, Florian Traverse <
> florian.traverse at allocab.com> wrote:
>
>> Hi all :)
>>
>> We encounter an issue since yesterday on our aerogear server running in
>> production for several months on OpenShift Online (
>> OPENSHIFT_AEROGEAR_PUSH_VERSION=1.0.3 ) :
>>
>> Management interface would report the handshake error as well, and none
>> of all our iOS pushes, whatever the `application`, whatever the `variant`,
>> would work.
>>
>> We're looking for what can go wrong in order to fix it. We still have
>> both RAM and disk available, and a `gear restart` would not help in the
>> matter.
>>
>> Here's what the stacktrace looks like in the logs, can anybody help ?
>>
>> ```
>> ERROR [com.notnoop.apns.internal.ApnsConnectionImpl] (EJB default - 4)
>> Couldn't send message after 3 retries.Message(Id=1; Token=<TOKEN>;
>> Payload={"<some_payload_property>":"<some numeric
>> value>","aps":{"alert":"<The notification text>","badge":-1}}):
>> javax.net.ssl.SSLHandshakeException:
>> sun.security.validator.ValidatorException: No trusted certificate found
>>     at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>> [jsse.jar:1.7.0_85]
>>     at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1916)
>> [jsse.jar:1.7.0_85]
>>     at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:279)
>> [jsse.jar:1.7.0_85]
>>     at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:273)
>> [jsse.jar:1.7.0_85]
>>     at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1469)
>> [jsse.jar:1.7.0_85]
>>     at
>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:213)
>> [jsse.jar:1.7.0_85]
>>     at sun.security.ssl.Handshaker.processLoop(Handshaker.java:913)
>> [jsse.jar:1.7.0_85]
>>     at sun.security.ssl.Handshaker.process_record(Handshaker.java:849)
>> [jsse.jar:1.7.0_85]
>>     at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1035)
>> [jsse.jar:1.7.0_85]
>>     at
>> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
>> [jsse.jar:1.7.0_85]
>>     at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:721)
>> [jsse.jar:1.7.0_85]
>>     at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
>> [jsse.jar:1.7.0_85]
>>     at java.io.OutputStream.write(OutputStream.java:75) [rt.jar:1.7.0_85]
>>     at
>> com.notnoop.apns.internal.ApnsConnectionImpl.sendMessage(ApnsConnectionImpl.java:322)
>> [apns-1.0.0.Beta5.jar:]
>>     at
>> com.notnoop.apns.internal.ApnsConnectionImpl.sendMessage(ApnsConnectionImpl.java:310)
>> [apns-1.0.0.Beta5.jar:]
>>     at
>> com.notnoop.apns.internal.ApnsServiceImpl.push(ApnsServiceImpl.java:46)
>> [apns-1.0.0.Beta5.jar:]
>>     at
>> com.notnoop.apns.internal.AbstractApnsService.push(AbstractApnsService.java:102)
>> [apns-1.0.0.Beta5.jar:]
>>     at
>> com.notnoop.apns.internal.ApnsServiceImpl.push(ApnsServiceImpl.java:36)
>> [apns-1.0.0.Beta5.jar:]
>>     at
>> org.jboss.aerogear.unifiedpush.message.sender.APNsPushNotificationSender.sendPushMessage(APNsPushNotificationSender.java:109)
>> [unifiedpush-push-1.0.3.jar:1.0.3]
>>     at
>> org.jboss.aerogear.unifiedpush.message.SenderServiceImpl.send(SenderServiceImpl.java:116)
>> [unifiedpush-push-1.0.3.jar:1.0.3]
>>     at sun.reflect.GeneratedMethodAccessor149.invoke(Unknown Source)
>> [:1.7.0_85]
>>     at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.7.0_85]
>>     at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_85]
>>     at
>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>>     at
>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
>>     at
>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>> [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>> [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>>     at
>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>> [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
>>     at
>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
>> [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>>     at
>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>> [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>> [wildfly-ee-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>     at
>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>>     at
>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>>     at
>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>>     at
>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>     at
>> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>>     at
>> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:79)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>     at
>> org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
>> [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>>     at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> [rt.jar:1.7.0_85]
>>     at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> [rt.jar:1.7.0_85]
>>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_85]
>>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>> Caused by: sun.security.validator.ValidatorException: No trusted
>> certificate found
>>     at
>> sun.security.validator.SimpleValidator.buildTrustedChain(SimpleValidator.java:394)
>> [rt.jar:1.7.0_85]
>>     at
>> sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:134)
>> [rt.jar:1.7.0_85]
>>     at sun.security.validator.Validator.validate(Validator.java:260)
>> [rt.jar:1.7.0_85]
>>     at
>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
>> [jsse.jar:1.7.0_85]
>>     at
>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
>> [jsse.jar:1.7.0_85]
>>     at
>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
>> [jsse.jar:1.7.0_85]
>>     at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1451)
>> [jsse.jar:1.7.0_85]
>>     ... 87 more
>>
>> 2015-11-05 04:32:39,596 WARNING [APNsPushNotificationSender] (EJB default
>> - 4) Error on &apos;ios&apos; delivery
>> 2015-11-05 04:40:00,169 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-26)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:21,553 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-30)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:26,675 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-33)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:28,864 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-34)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:30,969 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-37)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:33,150 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-36)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:36,375 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-39)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:43,324 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-43)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:46,273 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-41)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:48,448 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-40)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:50,514 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-42)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:52,733 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-45)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:55,093 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-46)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:56,742 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-44)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:40:58,947 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-51)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:41:01,469 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-50)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:41:03,297 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-52)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> 2015-11-05 04:41:09,376 WARN
>> [org.hibernate.hql.internal.ast.QueryTranslatorImpl] (default task-55)
>> HHH000104: firstResult/maxResults specified with collection fetch; applying
>> in memory!
>> --
>> Florian TRAVERSE
>> Software Architect
>>
>> Allocab, votre chauffeur sur-mesure
>> M. +33 6 12 39 66 50
>> A. 7 impasse Charles Petit, 75011 Paris
>> W. www.allocab.com
>> E. florian.traverse at allocab.com
>>
>> _______________________________________________
>> 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
>



-- 
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-users/attachments/20151105/f20a6f22/attachment-0001.html 

From florian.traverse at allocab.com  Fri Nov  6 11:24:40 2015
From: florian.traverse at allocab.com (Florian Traverse)
Date: Fri, 6 Nov 2015 09:24:40 -0700 (MST)
Subject: [Aerogear-users] Handshake issue when connecting to APNS (from
 OpenShift Online)
In-Reply-To: <CAAg5f2Ratmy9fOHuXnhUiDYDmPiwopuMzMWTZzqtTtbzPkCJ_g@mail.gmail.com>
References: <CAJ4FD9xMXaj4Qn6PTmPwp8u5wc-QpvFG1nqH613hFHjEfpgCEA@mail.gmail.com>
	<CAAg5f2SJqQZAa=fp4BH-RYU55OVJFigLqj06Kj+zZ+rjvy-HCw@mail.gmail.com>
	<CAAg5f2Ratmy9fOHuXnhUiDYDmPiwopuMzMWTZzqtTtbzPkCJ_g@mail.gmail.com>
Message-ID: <1446827080262-266.post@n5.nabble.com>

Thanks Matthias for your help,

Our certs are good until 2016 at least, so it was not the reason.


The solution was pretty simple, finally: we've just restarted the gear and
it worked pretty well then.


Yet the cause is still unknown, and this is not great for a production
server :/

Thanks,
Florian



--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-Handshake-issue-when-connecting-to-APNS-from-OpenShift-Online-tp263p266.html
Sent from the aerogear-users mailing list archive at Nabble.com.

From matzew at apache.org  Mon Nov  9 05:13:31 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 9 Nov 2015 11:13:31 +0100
Subject: [Aerogear-users] Handshake issue when connecting to APNS (from
 OpenShift Online)
In-Reply-To: <1446827080262-266.post@n5.nabble.com>
References: <CAJ4FD9xMXaj4Qn6PTmPwp8u5wc-QpvFG1nqH613hFHjEfpgCEA@mail.gmail.com>
	<CAAg5f2SJqQZAa=fp4BH-RYU55OVJFigLqj06Kj+zZ+rjvy-HCw@mail.gmail.com>
	<CAAg5f2Ratmy9fOHuXnhUiDYDmPiwopuMzMWTZzqtTtbzPkCJ_g@mail.gmail.com>
	<1446827080262-266.post@n5.nabble.com>
Message-ID: <CAAg5f2T+-9QwRruiDO3gtp3UYD9MCDEkLKX6tg4kYf3SdSbj7g@mail.gmail.com>

On Fri, Nov 6, 2015 at 5:24 PM, Florian Traverse <
florian.traverse at allocab.com> wrote:

> Thanks Matthias for your help,
>
> Our certs are good until 2016 at least, so it was not the reason.
>
>
> The solution was pretty simple, finally: we've just restarted the gear and
> it worked pretty well then.
>

Indeed - this sucks big times. How long was it up and running before? Would
like to understand the problem.
Thanks for sharing the stack-trace - I will check if similar problems have
been reported by other java-apns users.


BTW. Apple will move to http2 soon, that will allow us having a much more
straightforward connect to APNs.


>
>
> Yet the cause is still unknown, and this is not great for a production
> server :/
>
> Thanks,
> Florian
>
>
>
> --
> View this message in context:
> http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-Handshake-issue-when-connecting-to-APNS-from-OpenShift-Online-tp263p266.html
> Sent from the aerogear-users mailing list archive at Nabble.com.
> _______________________________________________
> 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-users/attachments/20151109/a5c4b821/attachment.html 

From dharmendra.sahu08 at hotmail.com  Tue Nov 10 08:08:15 2015
From: dharmendra.sahu08 at hotmail.com (Dharmendra Sahu)
Date: Tue, 10 Nov 2015 18:38:15 +0530
Subject: [Aerogear-users] Need help to set-up java-mpns with java web
	application
Message-ID: <BAY168-W13758F2F8693CC1E3A4E3EFE8140@phx.gbl>

Hello,
I have gone through your api and server and I want to use in my application.I have created windows mobile application.I want to use java-mpns api for push notification.I want to send push notification message from my java web-application to AeroGear UnifiedPush Server and Unified server to my windows mobile application.
OR
I would like to know if we could send push notification from my java web application to my windows mobile application.
Thanks for your support and help.
ThanksDharmendra Sahu
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151110/8cecd8ec/attachment.html 

From edewit at redhat.com  Wed Nov 11 03:12:21 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Wed, 11 Nov 2015 09:12:21 +0100
Subject: [Aerogear-users] Need help to set-up java-mpns with java web
	application
In-Reply-To: <BAY168-W13758F2F8693CC1E3A4E3EFE8140@phx.gbl>
References: <BAY168-W13758F2F8693CC1E3A4E3EFE8140@phx.gbl>
Message-ID: <CAO2B-fZ1WEUpFwmD3BrQi-S4TWQN073mJbafkFpXQTL2E0xoxQ@mail.gmail.com>

Hi Dharmendra,

So in the first case:
Install the aerogear-windows-push nuget package in your windows mobile app:

PM> Install-Package aerogear-windows-push

Install UPS and create an application and a mpns varaint then add the
following to your windows app:

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    PushConfig pushConfig = new PushConfig() {
        UnifiedPushUri = new Uri(""), VariantId = "", VariantSecret = ""
    }; //[1]
    Registration registration = new MpnsRegistration();
    registration.PushReceivedEvent += HandleNotification;
    registration.Register(pushConfig);
}
void HandleNotification(object sender, PushReceivedEvent e)
{
    Debug.WriteLine(e.Args.Message);
}


Fill out [1] with the location of your UPS and the id and secret from your
Mpns variant

If you have done that correctly you'll see a installation on the UPS
console. Now you can use the Java Sender to send a message to UPS that will
in turn send it to your device.

PushSender defaultPushSender =
DefaultPushSender.withRootServerURL("http://localhost:8080/ag-push")
                .pushApplicationId("c7fc6525-5506-4ca9-9cf1-55cc261ddb9c")
                .masterSecret("8b2f43a9-23c8-44fe-bee9-d6b0af9e316b")
                .build();

See:
https://github.com/aerogear/aerogear-unifiedpush-java-client
https://github.com/aerogear/aerogear-windows-push
https://aerogear.org/docs/unifiedpush/ups_userguide/index/

Other case without UPS

Register your app with Mpns yourself have a look at the source code of the
aerogear-windows-push to see how to register:

            const string channelName = "ToastChannel";

            var channel = HttpNotificationChannel.Find(channelName) ?? new
HttpNotificationChannel(channelName);

            var tcs = new TaskCompletionSource<string>();
            channel.ChannelUriUpdated += (s, e) => {
tcs.TrySetResult(e.ChannelUri.ToString()); };
            channel.ErrorOccurred += (s, e) => { tcs.TrySetException(new
Exception(e.Message)); };

            channel.ShellToastNotificationReceived +=
PushChannel_ShellToastNotificationReceived;

            channel.Open();
            channel.BindToShellToast();
            return await tcs.Task;

Use java-mpns in your app directly to send a message to the device:


   1.

   MpnsService service = MPNS.newService().build();

   2.

   MpnsMessage notification = MPNS.newMessage()
       .tile().count(2).title("Tile message")
       .build();
   String subscriptionUri = "https://..../" //need to get this from the device
   service.push(subscriptionUri, notification);


Downside to this approach is that when you have other clients like android
or ios then you'll need to manage the dispatching yourself that is where
UPS is handy and you need a way to get the subscriptionUri from the device
to your java backend.


On Tue, Nov 10, 2015 at 2:08 PM, Dharmendra Sahu <
dharmendra.sahu08 at hotmail.com> wrote:

> Hello,
>
> I have gone through your api and server and I want to use in my
> application.
> I have created windows mobile application.
> I want to use java-mpns api for push notification.
> I want to send push notification message from my java web-application to
> AeroGear UnifiedPush Server and Unified server to my windows mobile
> application.
>
> OR
>
> I would like to know if we could send push notification from my java web
> application to my windows mobile application.
>
> Thanks for your support and help.
>
> Thanks
> Dharmendra Sahu
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>


-- 
Cheers,
       Erik Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151111/16331fe5/attachment.html 

From edewit at redhat.com  Wed Nov 11 03:52:42 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Wed, 11 Nov 2015 09:52:42 +0100
Subject: [Aerogear-users] Cordova plugin
In-Reply-To: <1446233940043-262.post@n5.nabble.com>
References: <1446233940043-262.post@n5.nabble.com>
Message-ID: <CAO2B-fa8s8KgM9hpeRFoZOWxN54Ejs1j_VwSwZwM=TQbfgj_zg@mail.gmail.com>

Hi,

For starters push is meant to notify your app user of things, it's not a
secure and / or reliable way to transfer data. The way we created the
cordova push plugin is to have the messages show up similar on all
platforms as well. That is why the message gets replaced, because this is
also the behavior on iOS. There has been a feature request to use stacked
messages on android AGCORDOVA-113
<https://issues.jboss.org/browse/AGCORDOVA-113> this might be something
that will enable us to have the apps event handler to get called with both
messages.

-- 
Cheers,
       Erik Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151111/e5c34bd7/attachment-0001.html 

From jerome at velociter.fr  Wed Nov 18 09:19:13 2015
From: jerome at velociter.fr (jvelo)
Date: Wed, 18 Nov 2015 07:19:13 -0700 (MST)
Subject: [Aerogear-users] Handshake issue when connecting to APNS (from
 OpenShift Online)
In-Reply-To: <CAAg5f2T+-9QwRruiDO3gtp3UYD9MCDEkLKX6tg4kYf3SdSbj7g@mail.gmail.com>
References: <CAJ4FD9xMXaj4Qn6PTmPwp8u5wc-QpvFG1nqH613hFHjEfpgCEA@mail.gmail.com>
	<CAAg5f2SJqQZAa=fp4BH-RYU55OVJFigLqj06Kj+zZ+rjvy-HCw@mail.gmail.com>
	<CAAg5f2Ratmy9fOHuXnhUiDYDmPiwopuMzMWTZzqtTtbzPkCJ_g@mail.gmail.com>
	<1446827080262-266.post@n5.nabble.com>
	<CAAg5f2T+-9QwRruiDO3gtp3UYD9MCDEkLKX6tg4kYf3SdSbj7g@mail.gmail.com>
Message-ID: <1447856353424-276.post@n5.nabble.com>

Hello,

FYI, we've had exactly this issue (on OpenShift as well).

Restarting the gear "solved" the problem.

Regards,
J?r?me



--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-Handshake-issue-when-connecting-to-APNS-from-OpenShift-Online-tp263p276.html
Sent from the aerogear-users mailing list archive at Nabble.com.


From matzew at apache.org  Wed Nov 18 09:32:59 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 18 Nov 2015 15:32:59 +0100
Subject: [Aerogear-users] Handshake issue when connecting to APNS (from
 OpenShift Online)
In-Reply-To: <1447856353424-276.post@n5.nabble.com>
References: <CAJ4FD9xMXaj4Qn6PTmPwp8u5wc-QpvFG1nqH613hFHjEfpgCEA@mail.gmail.com>
	<CAAg5f2SJqQZAa=fp4BH-RYU55OVJFigLqj06Kj+zZ+rjvy-HCw@mail.gmail.com>
	<CAAg5f2Ratmy9fOHuXnhUiDYDmPiwopuMzMWTZzqtTtbzPkCJ_g@mail.gmail.com>
	<1446827080262-266.post@n5.nabble.com>
	<CAAg5f2T+-9QwRruiDO3gtp3UYD9MCDEkLKX6tg4kYf3SdSbj7g@mail.gmail.com>
	<1447856353424-276.post@n5.nabble.com>
Message-ID: <CAAg5f2QtjpY9XWw4gOQq=BWRP1HNG__iEU0pyp1GFfcK-c-EPw@mail.gmail.com>

J?r?me,

thanks for the heads-up. We will look into this - mind sharing more
details, incase it happens again?

Thanks,
Matthias

On Wed, Nov 18, 2015 at 3:19 PM, jvelo <jerome at velociter.fr> wrote:

> Hello,
>
> FYI, we've had exactly this issue (on OpenShift as well).
>
> Restarting the gear "solved" the problem.
>
> Regards,
> J?r?me
>
>
>
> --
> View this message in context:
> http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-Handshake-issue-when-connecting-to-APNS-from-OpenShift-Online-tp263p276.html
> Sent from the aerogear-users mailing list archive at Nabble.com.
>
> _______________________________________________
> 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-users/attachments/20151118/c8e75f17/attachment.html 

From jerome at velociter.fr  Wed Nov 18 09:43:14 2015
From: jerome at velociter.fr (jvelo)
Date: Wed, 18 Nov 2015 07:43:14 -0700 (MST)
Subject: [Aerogear-users] Handshake issue when connecting to APNS (from
 OpenShift Online)
In-Reply-To: <CAAg5f2QtjpY9XWw4gOQq=BWRP1HNG__iEU0pyp1GFfcK-c-EPw@mail.gmail.com>
References: <CAJ4FD9xMXaj4Qn6PTmPwp8u5wc-QpvFG1nqH613hFHjEfpgCEA@mail.gmail.com>
	<CAAg5f2SJqQZAa=fp4BH-RYU55OVJFigLqj06Kj+zZ+rjvy-HCw@mail.gmail.com>
	<CAAg5f2Ratmy9fOHuXnhUiDYDmPiwopuMzMWTZzqtTtbzPkCJ_g@mail.gmail.com>
	<1446827080262-266.post@n5.nabble.com>
	<CAAg5f2T+-9QwRruiDO3gtp3UYD9MCDEkLKX6tg4kYf3SdSbj7g@mail.gmail.com>
	<1447856353424-276.post@n5.nabble.com>
	<CAAg5f2QtjpY9XWw4gOQq=BWRP1HNG__iEU0pyp1GFfcK-c-EPw@mail.gmail.com>
Message-ID: <1447857794947-278.post@n5.nabble.com>

Sure,

Aerogear version is 1.0.2

Here is what we had in the log when the handshake failed :

2015/11/14 12:37:51,540 WARNING [APNsPushNotificationSender] (EJB default -
10) Error on &apos;ios&apos; delivery
2015/11/14 12:37:51,550 WARNING [APNsPushNotificationSender] (EJB default -
10) Error on &apos;ios&apos; delivery
2015/11/14 12:37:51,566 INFO  [GCMPushNotificationSender] (EJB default - 10)
Sending payload for [122] devices to GCM
2015/11/14 12:37:51,641 INFO  [GCMPushNotificationSender] (EJB default - 10)
Message to GCM has been submitted

==> aerogear-push/logs/server.log.2015-11-15 <==
	at
sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:134)
[rt.jar:1.7.0_85]
	at sun.security.validator.Validator.validate(Validator.java:260)
[rt.jar:1.7.0_85]
	at
sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
	at
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
	at
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
	at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1451)
	... 60 more

Please let me know if there is anything more I can provide you with.

Regards,
J?r?me



--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-Handshake-issue-when-connecting-to-APNS-from-OpenShift-Online-tp263p278.html
Sent from the aerogear-users mailing list archive at Nabble.com.


From xfdeng at hotmail.com  Tue Nov 10 17:26:32 2015
From: xfdeng at hotmail.com (jeff01)
Date: Tue, 10 Nov 2015 15:26:32 -0700 (MST)
Subject: [Aerogear-users] Aerogear UPS 1.1.0.Final installation error:
 AbstractServiceCache is not proxyable
Message-ID: <1447194392665-269.post@n5.nabble.com>

Hi, 

I have a question regarding Aerogear UPS 1.1.0.Final installation. I got an
exception in the log: 

org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001435 Normal
scoped bean class org.jboss.aerogear.u                                                                                
nifiedpush.message.cache.AbstractServiceCache is not proxyable because it
has no no-args constructor - Managed Bean [class
org.jboss.aerogear.unifiedpush.message.cache.ApnsService]                                                                

Can anyone shed some light on what's going on? That's a fresh install on
jboss as 7 running openJDK 1.7.

Could the root cause be that our JBoss version is too low? What is JBoss
version requirement for installing Aerogear UPS 1.1.0.Final? In different
places, AeroGear documentation refers to different versions of JBoss for
this version of Aerogear UPS: JBoss EAP 6.4.0 GA, or Jboss EAP 6.3. But I am
not sure if this is the minimum version of JBoss to run AeroGeear UPS
1.1.0.Final.

Our JBoss: JBoss MSC version 1.0.4.GA-redhat-1, JBoss EAP 6.1.1.GA.

Did any of you run AeroGeear UPS 1.1.0.Final successfully in this or similar
versions of JBoss EAP?


Thank you.




--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-UPS-1-1-0-Final-installation-error-AbstractServiceCache-is-not-proxyable-tp269.html
Sent from the aerogear-users mailing list archive at Nabble.com.

From xfdeng at hotmail.com  Tue Nov 10 17:30:53 2015
From: xfdeng at hotmail.com (jeff01)
Date: Tue, 10 Nov 2015 15:30:53 -0700 (MST)
Subject: [Aerogear-users] Need help to set-up java-mpns with java web
 application
In-Reply-To: <BAY168-W13758F2F8693CC1E3A4E3EFE8140@phx.gbl>
References: <BAY168-W13758F2F8693CC1E3A4E3EFE8140@phx.gbl>
Message-ID: <1447194653985-270.post@n5.nabble.com>

To the best of my knowledge, you can send push notifications to your app with
a Java or .net client using AeroGear's sender api, but not directly. It has
to be through Windows Push Notofication Network.



--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-Need-help-to-set-up-java-mpns-with-java-web-application-tp268p270.html
Sent from the aerogear-users mailing list archive at Nabble.com.

From xfdeng at hotmail.com  Tue Nov 10 17:36:06 2015
From: xfdeng at hotmail.com (jeff01)
Date: Tue, 10 Nov 2015 15:36:06 -0700 (MST)
Subject: [Aerogear-users] GCM Registration Not happening
In-Reply-To: <CAHZAh5DBor_fvo7qL0p87AdALNMt0OgAqrrK6r6Etq9C=WEQGQ@mail.gmail.com>
References: <CAHZAh5DBor_fvo7qL0p87AdALNMt0OgAqrrK6r6Etq9C=WEQGQ@mail.gmail.com>
Message-ID: <1447194966929-271.post@n5.nabble.com>

As error message indicated: "NotRegistered".

Your app would not receive any nptifications if it was not registered with
GCM/AeroGear before.



--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-GCM-Registration-Not-happening-tp258p271.html
Sent from the aerogear-users mailing list archive at Nabble.com.

From xfdeng at hotmail.com  Wed Nov 11 19:51:43 2015
From: xfdeng at hotmail.com (jeff01)
Date: Wed, 11 Nov 2015 17:51:43 -0700 (MST)
Subject: [Aerogear-users] Aerogear UPS 1.1.0.Final installation error:
 AbstractServiceCache is not proxyable
In-Reply-To: <1447194392665-269.post@n5.nabble.com>
References: <1447194392665-269.post@n5.nabble.com>
Message-ID: <1447289503214-274.post@n5.nabble.com>

Anyone experienced this and can help?

Thanks in advance.



--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-UPS-1-1-0-Final-installation-error-AbstractServiceCache-is-not-proxyable-tp269p274.html
Sent from the aerogear-users mailing list archive at Nabble.com.

From xfdeng at hotmail.com  Thu Nov 12 16:07:17 2015
From: xfdeng at hotmail.com (jeff01)
Date: Thu, 12 Nov 2015 14:07:17 -0700 (MST)
Subject: [Aerogear-users] Aerogear UPS 1.1.0.Final installation error:
 AbstractServiceCache is not proxyable
In-Reply-To: <1447194392665-269.post@n5.nabble.com>
References: <1447194392665-269.post@n5.nabble.com>
Message-ID: <1447362437866-275.post@n5.nabble.com>

In other words, has anyone successfully run AeroGear 1.1.0.Final on Jboss EAP
6.1.0?



--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-UPS-1-1-0-Final-installation-error-AbstractServiceCache-is-not-proxyable-tp269p275.html
Sent from the aerogear-users mailing list archive at Nabble.com.

From jerome at 46cl.fr  Tue Nov 17 11:07:57 2015
From: jerome at 46cl.fr (Jerome Velociter)
Date: Tue, 17 Nov 2015 17:07:57 +0100
Subject: [Aerogear-users] Sudden "No trusted certificate found" error when
	pushing to iOS
Message-ID: <etPan.564b50dd.4c91a8ce.9ad6@libair>

?
Hi all,

I have have an app that subscribe to push notifications sent via Aerogear on openshift, it ahs successfully sent notifications for a long time, but now fails to push to Apple APN with this error : "Error sending payload to APNs server: sun.security.validator.ValidatorException: No trusted certificate found?. The?APNs Production iOS certificate is still valid (expires in 2016) and no other change in the mean time.

Any idea what could cause this ?

I?ve read this thread :?http://lists.jboss.org/pipermail/aerogear-dev/2015-January/010588.html?but could not find anything relevant to my issue.

How can I debug further the issue ?

Thanks in advance

--  
J?r?me Velociter



From matzew at apache.org  Thu Nov 19 09:26:56 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 19 Nov 2015 15:26:56 +0100
Subject: [Aerogear-users] Aerogear UPS 1.1.0.Final installation error:
 AbstractServiceCache is not proxyable
In-Reply-To: <1447362437866-275.post@n5.nabble.com>
References: <1447194392665-269.post@n5.nabble.com>
	<1447362437866-275.post@n5.nabble.com>
Message-ID: <CAAg5f2TByk1tL5cYE4HGDe1=QKdHgNHeAeY96WNNjKqKRgBwcA@mail.gmail.com>

Hello jeff01,

unfortunately the UPS is not supporting running on JBoss AS7, or EAP 6.1.

We do require WildFly-8 or for EAP 6.4.0:
https://aerogear.org/docs/unifiedpush/ups_userguide/index/#server-installation

Cheers,
Matthias

On Thu, Nov 12, 2015 at 10:07 PM, jeff01 <xfdeng at hotmail.com> wrote:

> In other words, has anyone successfully run AeroGear 1.1.0.Final on Jboss
> EAP
> 6.1.0?
>
>
>
> --
> View this message in context:
> http://aerogear-users.1116366.n5.nabble.com/Aerogear-UPS-1-1-0-Final-installation-error-AbstractServiceCache-is-not-proxyable-tp269p275.html
> Sent from the aerogear-users mailing list archive at Nabble.com.
> _______________________________________________
> 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-users/attachments/20151119/ef942f7f/attachment-0001.html 

From matzew at apache.org  Fri Nov 20 03:23:08 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 20 Nov 2015 09:23:08 +0100
Subject: [Aerogear-users] Sudden "No trusted certificate found" error
 when pushing to iOS
In-Reply-To: <etPan.564b50dd.4c91a8ce.9ad6@libair>
References: <etPan.564b50dd.4c91a8ce.9ad6@libair>
Message-ID: <CAAg5f2SCexaYvjePPmdOVcBw4jurE70XfAD2uztuxbX7RFcQAQ@mail.gmail.com>

Hi, Jerome,

it's a weird error - recently a few other OpenShift users reported the
same. They had to, unfortunately, reboot the instance of OpenShift.

I will file a JIRA bug ticket to track this - as it is an annoying issue

On Tue, Nov 17, 2015 at 5:07 PM, Jerome Velociter <jerome at 46cl.fr> wrote:

>
> Hi all,
>
> I have have an app that subscribe to push notifications sent via Aerogear
> on openshift, it ahs successfully sent notifications for a long time, but
> now fails to push to Apple APN with this error : "Error sending payload to
> APNs server: sun.security.validator.ValidatorException: No trusted
> certificate found?. The APNs Production iOS certificate is still valid
> (expires in 2016) and no other change in the mean time.
>
> Any idea what could cause this ?
>
> I?ve read this thread :
> http://lists.jboss.org/pipermail/aerogear-dev/2015-January/010588.html but
> could not find anything relevant to my issue.
>
> How can I debug further the issue ?
>
> Thanks in advance
>
> --
> J?r?me Velociter
>
>
> _______________________________________________
> 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-users/attachments/20151120/2e9a01ca/attachment.html 

From rob.aerogear at robertwillett.com  Wed Nov 25 04:14:49 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Wed, 25 Nov 2015 09:14:49 +0000
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
Message-ID: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>

Hi,

We?ve got the Unified Push Server working on the OpenShift platform. 
No real issues once we?d understood the point of aliases.

We can send notifications quite happily and see whats going on. We use 
Perl for our backend servers and so we wrote a small Perl interface. If 
anybody wants the code for the Perl interface let me know and we?ll 
pass it on. We can?t claim a lot of credit for a simple piece of code 
:)

Anyway, one of edge use-cases would be to delete notification or set of 
notifications when the app is running but in the background on iOS.

We want to do this as the user can receive a high number of 
notifications (> 10) when the app is in the background. Notifications 
come in groups and provide traffic updates, so a user may get a new 
group of 3-4 traffic updates, this new group completely supersedes ANY 
previous update. Our data is valuable when fresh and useless when over 
10 minutes old.

Whilst we can simply ignore old notifications, UX testing has shown the 
users don?t like having old notifications sitting round. We know that 
the users can delete them individually or delete the lot from the 
notification drawer OR can simply bring the app out of the background 
BUT they don?t like doing that.

So what we want to do is delete old notifications, we were hoping for 
the ability to call a JavaScript function with say a parameter to 
identify notifications by a group or something, but we could accept 
deleting the lot and inserting local notifications instead.

We know that we can send content-available and have stuff pulled from a 
server in the background. This option is quite difficult for us and has 
some complexity identifying when the app is not started up. The simplest 
option is delete some or all of the notifications.

Does anybody know if this is possible or any other suggestions?

Thanks

Rob

From alexandre.balleste at udl.cat  Wed Nov 25 04:58:32 2015
From: alexandre.balleste at udl.cat (=?UTF-8?B?QWxleCBCYWxsZXN0w6k=?=)
Date: Wed, 25 Nov 2015 10:58:32 +0100
Subject: [Aerogear-users] category_pkey duplicated
Message-ID: <56558648.6020100@udl.cat>

Hi, I installed an Unified push server 1.0.3 in a Wildfly 9 running on 
postgresql. We are having a bug about constrain violation over the 
restriction category_pkey. So I understand that we are trying to create 
categories with the same Id. Looking at this table I see unordered ids 
with negative numbers positive, ... http://pastebin.com/PmGWvivH

Any idea what's going on? Is hibernate ignoring the sequence?



-- 

Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
====================
Universitat de Lleida

?rea de sistemes d'Informaci? i Comunicacions

Analista/Programador


University of Lleida

Information and Communication Systems Service


Tlf: +34 973 702148

Fax: +34 973 702130

=====================

Av?s legal/Aviso legal/Avertiment legal/Legal notice 
<http://www.imatge.udl.cat/avis_legal_lopd.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151125/d8bd1b7d/attachment.html 

From matzew at apache.org  Wed Nov 25 05:07:20 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 25 Nov 2015 11:07:20 +0100
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
Message-ID: <CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>

On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
rob.aerogear at robertwillett.com> wrote:

> Hi,
>
> We?ve got the Unified Push Server working on the OpenShift platform.
> No real issues once we?d understood the point of aliases.
>
> We can send notifications quite happily and see whats going on. We use
> Perl for our backend servers and so we wrote a small Perl interface. If
> anybody wants the code for the Perl interface let me know and we?ll
> pass it on. We can?t claim a lot of credit for a simple piece of code
> :)
>

sure, I think that would be awesome, if you could publish it on github.
We will promote if for other perl users!


>
> Anyway, one of edge use-cases would be to delete notification or set of
> notifications when the app is running but in the background on iOS.
>
> We want to do this as the user can receive a high number of
> notifications (> 10) when the app is in the background. Notifications
> come in groups and provide traffic updates, so a user may get a new
> group of 3-4 traffic updates, this new group completely supersedes ANY
> previous update. Our data is valuable when fresh and useless when over
> 10 minutes old.
>
> Whilst we can simply ignore old notifications, UX testing has shown the
> users don?t like having old notifications sitting round. We know that
> the users can delete them individually or delete the lot from the
> notification drawer OR can simply bring the app out of the background
> BUT they don?t like doing that.
>
> So what we want to do is delete old notifications, we were hoping for
> the ability to call a JavaScript function with say a parameter to
> identify notifications by a group or something, but we could accept
> deleting the lot and inserting local notifications instead.
>
> We know that we can send content-available and have stuff pulled from a
> server in the background. This option is quite difficult for us and has
> some complexity identifying when the app is not started up. The simplest
> option is delete some or all of the notifications.
>
> Does anybody know if this is possible or any other suggestions?
>

I think that's an interesting idea. Erik Jan recently did an update for
message, on Cordova, to actually stack em:
https://github.com/aerogear/aerogear-cordova-push/pull/81

Perhaps we could have a 'delete' feature too. Mind filing a JIRA against:
https://issues.jboss.org/projects/AGCORDOVA
(you need to have an account in order create tickets)

Cheers!
Matthias


>
> Thanks
>
> Rob
> _______________________________________________
> 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-users/attachments/20151125/7399371b/attachment.html 

From matzew at apache.org  Wed Nov 25 05:08:32 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 25 Nov 2015 11:08:32 +0100
Subject: [Aerogear-users] category_pkey duplicated
In-Reply-To: <56558648.6020100@udl.cat>
References: <56558648.6020100@udl.cat>
Message-ID: <CAAg5f2Rtr2m9BJo88V3gbeW3AGGksrwNBw-cn=Bd8pN253216w@mail.gmail.com>

oh, not sure, atm - mind filing a ticket at
https://jira.jboss.org/browse/AGPUSH  ?

On Wed, Nov 25, 2015 at 10:58 AM, Alex Ballest? <alexandre.balleste at udl.cat>
wrote:

> Hi, I installed an Unified push server 1.0.3 in a Wildfly 9 running on
> postgresql. We are having a bug about constrain violation over the
> restriction category_pkey. So I understand that we are trying to create
> categories with the same Id. Looking at this table I see unordered ids with
> negative numbers positive, ...  http://pastebin.com/PmGWvivH
>
> Any idea what's going on? Is hibernate ignoring the sequence?
>
>
>
> --
>
> Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> ?rea de sistemes d'Informaci? i Comunicacions
>
> Analista/Programador
>
> University of Lleida
>
> Information and Communication Systems Service
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Av?s legal/Aviso legal/Avertiment legal/Legal notice
> <http://www.imatge.udl.cat/avis_legal_lopd.html>
>
> _______________________________________________
> 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-users/attachments/20151125/934e2316/attachment-0001.html 

From edewit at redhat.com  Wed Nov 25 05:50:13 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Wed, 25 Nov 2015 11:50:13 +0100
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
	<CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
Message-ID: <CAO2B-fbfhaNFuZdg+4YYyei7A9vJ=+4Fr4+hQTO66xOTUF+gsg@mail.gmail.com>

Hi Rob,

Like Matthias already told you on Android managing notifications and
changing how they look is much simpler then on iOS. On iOS you can cancel
all the remote notifications, but not some.

Corrine had this idea: send your notifications as 'background
notifications' (e.g. 'content-available' flag set) then your app will be
notified, but nothing will show up in the Notification area. You can use
local notifications to create the notification in the notification area,
because these you can cancel. You decide how they show up and even group
them. The cordova plugin to create local notifications is called
'cordova-plugin-local-notifications' [1]

So you will have to deal with the complexities of background notifications
for this to work, but to determine if the app is in the foreground when the
background notification arrives there is a boolean on the notification to
help [2]

Although I must advise you sending large volumes of messages might not be a
great way to use push notifications, it's meant to inform the user that
something important has happened it should be personal and engage the
users. Users could also opt to turn off the push notifications so you can't
use it to transfer data.

Hope this helps

[1] https://github.com/katzer/cordova-plugin-local-notifications
[2]
https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification

On Wed, Nov 25, 2015 at 11:07 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
> rob.aerogear at robertwillett.com> wrote:
>
>> Hi,
>>
>> We?ve got the Unified Push Server working on the OpenShift platform.
>> No real issues once we?d understood the point of aliases.
>>
>> We can send notifications quite happily and see whats going on. We use
>> Perl for our backend servers and so we wrote a small Perl interface. If
>> anybody wants the code for the Perl interface let me know and we?ll
>> pass it on. We can?t claim a lot of credit for a simple piece of code
>> :)
>>
>
> sure, I think that would be awesome, if you could publish it on github.
> We will promote if for other perl users!
>
>
>>
>> Anyway, one of edge use-cases would be to delete notification or set of
>> notifications when the app is running but in the background on iOS.
>>
>> We want to do this as the user can receive a high number of
>> notifications (> 10) when the app is in the background. Notifications
>> come in groups and provide traffic updates, so a user may get a new
>> group of 3-4 traffic updates, this new group completely supersedes ANY
>> previous update. Our data is valuable when fresh and useless when over
>> 10 minutes old.
>>
>> Whilst we can simply ignore old notifications, UX testing has shown the
>> users don?t like having old notifications sitting round. We know that
>> the users can delete them individually or delete the lot from the
>> notification drawer OR can simply bring the app out of the background
>> BUT they don?t like doing that.
>>
>> So what we want to do is delete old notifications, we were hoping for
>> the ability to call a JavaScript function with say a parameter to
>> identify notifications by a group or something, but we could accept
>> deleting the lot and inserting local notifications instead.
>>
>> We know that we can send content-available and have stuff pulled from a
>> server in the background. This option is quite difficult for us and has
>> some complexity identifying when the app is not started up. The simplest
>> option is delete some or all of the notifications.
>>
>> Does anybody know if this is possible or any other suggestions?
>>
>
> I think that's an interesting idea. Erik Jan recently did an update for
> message, on Cordova, to actually stack em:
> https://github.com/aerogear/aerogear-cordova-push/pull/81
>
> Perhaps we could have a 'delete' feature too. Mind filing a JIRA against:
> https://issues.jboss.org/projects/AGCORDOVA
> (you need to have an account in order create tickets)
>
> Cheers!
> Matthias
>
>
>>
>> Thanks
>>
>> Rob
>> _______________________________________________
>> 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-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>


-- 
Cheers,
       Erik Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151125/b3d4c4bd/attachment.html 

From rob.aerogear at robertwillett.com  Wed Nov 25 07:00:49 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Wed, 25 Nov 2015 12:00:49 +0000
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
	<CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
Message-ID: <B064E062-68F1-4001-830B-8E9C8EF47506@robertwillett.com>

Matthias,

Thanks for the prompt and helpful reply.

We had a quick look at the stacking, as expected it seems to be for 
Android (which is no surprise at all). I am not an expert on iOS (or 
anything else) but as far as I know, stacking is impossible on iOS. 
We?re spending more and more time on getting the notifications right, 
its turned out to be significantly more complicated than we thought and 
one of the areas where we have two distinct lines of code in our Cordova 
app.

I?ll raise JIRA for our ideas and let people ponder on that. In the 
last three weeks, we?ve tried four biggish vendors for Push 
notifications and we?ve had issues with all of them. Amazon, Parse, 
Urban Airship, OneSignal. Some are money issues (thats always the way), 
some are incredibly inflexible (Amazon), some don?t handle 
content-available, some don?t really support Cordova. Its been 
hardwork and we really, really want UPS to work for us. We?re tired of 
testing notifications on yet another system :)

I?ll put in on github but the code is pretty simple so I?ll put it 
here as well as we?re not big users off github and it might takes us a 
while to work it out. We?re rather old-school and like Emacs, Perl and 
dead simple stuff like that. We?ll try and work it out though

Best wisher,

Rob

This is untested code as-is, we just pulled it straight out the testing 
file. We know it works in our system but I haven?t tested this 
simplified version. The github one will be tested though.

```
#!/usr/bin/perl -w

use strict;
use warnings;
use Net::Curl::Easy qw(/^CURLOPT_.*/);
use JSON;

sub SendAeroGearNotification
{
     my ($url , $username , $password , $config) = @_;
     my $curl = Net::Curl::Easy->new;
     my $json = JSON->new();
     my $response_body;

     my $json_string = $json->encode($config);

     print "json string $json_string\n";

     $curl->setopt( CURLOPT_URL, $url);
     $curl->setopt( CURLOPT_SSL_VERIFYHOST , 0);
     $curl->setopt( CURLOPT_SSL_VERIFYPEER , 0);

     $curl->setopt( CURLOPT_USERPWD , "$username:$password");
     $curl->setopt( CURLOPT_HTTPHEADER, ['Content-Type: 
application/json' ,
                                         'Accept: application/json']);
     $curl->setopt( CURLOPT_POST , 1);
     $curl->setopt( CURLOPT_POSTFIELDS , $json_string);

     $curl->setopt( CURLOPT_WRITEDATA , \$response_body);

     $curl->perform;
     print "AeroGear Reponse=".Dumper($response_body);
}

	my $notification_config = {
                  variants => [ ?<<VARIANT ID>>? ] ,
                  alias => [ ?alias1? , ?alias2? , ?alias3? 
] ,
                  ttl => 600 ,
                  message => {
         		    alert => $contents ,
                      'content-available' => JSON::true ,
                      data => {
						key1 => value1 ,
						key2 => value2
                      }
                  }
              };

	SendAeroGearNotification("https://<<OPENSHIFT GEAR 
NAME>>.rhcloud.com/ag-push/rest/sender" ,
                              ?<<USERNAME>>? ,
                              ?<<PASSWORD>>? , 
$notification_config);
````
On 25 Nov 2015, at 10:07, Matthias Wessendorf wrote:

> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
> rob.aerogear at robertwillett.com> wrote:
>
>> Hi,
>>
>> We?ve got the Unified Push Server working on the OpenShift 
>> platform.
>> No real issues once we?d understood the point of aliases.
>>
>> We can send notifications quite happily and see whats going on. We 
>> use
>> Perl for our backend servers and so we wrote a small Perl interface. 
>> If
>> anybody wants the code for the Perl interface let me know and we?ll
>> pass it on. We can?t claim a lot of credit for a simple piece of 
>> code
>> :)
>>
>
> sure, I think that would be awesome, if you could publish it on 
> github.
> We will promote if for other perl users!
>
>
>>
>> Anyway, one of edge use-cases would be to delete notification or set 
>> of
>> notifications when the app is running but in the background on iOS.
>>
>> We want to do this as the user can receive a high number of
>> notifications (> 10) when the app is in the background. Notifications
>> come in groups and provide traffic updates, so a user may get a new
>> group of 3-4 traffic updates, this new group completely supersedes 
>> ANY
>> previous update. Our data is valuable when fresh and useless when 
>> over
>> 10 minutes old.
>>
>> Whilst we can simply ignore old notifications, UX testing has shown 
>> the
>> users don?t like having old notifications sitting round. We know 
>> that
>> the users can delete them individually or delete the lot from the
>> notification drawer OR can simply bring the app out of the background
>> BUT they don?t like doing that.
>>
>> So what we want to do is delete old notifications, we were hoping for
>> the ability to call a JavaScript function with say a parameter to
>> identify notifications by a group or something, but we could accept
>> deleting the lot and inserting local notifications instead.
>>
>> We know that we can send content-available and have stuff pulled from 
>> a
>> server in the background. This option is quite difficult for us and 
>> has
>> some complexity identifying when the app is not started up. The 
>> simplest
>> option is delete some or all of the notifications.
>>
>> Does anybody know if this is possible or any other suggestions?
>>
>
> I think that's an interesting idea. Erik Jan recently did an update 
> for
> message, on Cordova, to actually stack em:
> https://github.com/aerogear/aerogear-cordova-push/pull/81
>
> Perhaps we could have a 'delete' feature too. Mind filing a JIRA 
> against:
> https://issues.jboss.org/projects/AGCORDOVA
> (you need to have an account in order create tickets)
>
> Cheers!
> Matthias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151125/6f5b0067/attachment.html 

From rob.aerogear at robertwillett.com  Wed Nov 25 07:30:22 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Wed, 25 Nov 2015 12:30:22 +0000
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <CAO2B-fbfhaNFuZdg+4YYyei7A9vJ=+4Fr4+hQTO66xOTUF+gsg@mail.gmail.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
	<CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
	<CAO2B-fbfhaNFuZdg+4YYyei7A9vJ=+4Fr4+hQTO66xOTUF+gsg@mail.gmail.com>
Message-ID: <92114729-9182-456D-996D-F6A2BA055123@robertwillett.com>

Erik,

Thanks for the thoughtful reply.

Great minds think alike :)

We have already worked through this as an option and it is probably the 
likeliest way forward for us. Indeed your notes and ours are almost 
identical.

You (or Corrine) have correctly identified the pitfalls regarding 
background and foreground. There is one other case and thats when the 
app is not actually started up. We still want to send them notifications 
(at least for a while) alerting them to traffic issues. After a day or 
so, we?ll throttle back these notifications but at least for a few 
hours or a day, we need to send them out. We can?t use the 
content-available flag as the app isn?t running (in either bg or fg) 
to handle the flag. So we have to try to work out if the app is 
?alive? or not, if the app is not alive we send down full-fat 
notifications, this means no content-available flag and full information 
to be displayed in the notification drawer.

Our potential solution has us send out a single silent notification to 
everybody who needs to be sent one. The device segmentation to determine 
who gets information is already done by us. The payload for the silent 
notification is actually empty and its used as a signalling mechanism. 
This tells the app when it is in the fg or bg to phone home and get a 
specific payload for that user. When the app contacts the backend 
database to retrieve the payload, we flag the app as alive and working.

If we send out a silent notification but never get a response to get a 
payload, then we flag the app as not started. After every batch of 
silent notifications are sent, 60 secs later, we then do a second cycle 
looking at whether the devices have NOT responded. If the app has not 
responded then we move to full notifications for that device and don?t 
use content-available. Once the user clicks on a notification and starts 
the app up, we can see that and we move them into the ?alive? state, 
so next time we send silent notifications.

The process diagram is a lot simpler than my explanation :)

The other reason for sending a single silent notification with little 
information in and to get the app to respond to that single notification 
is quite subtle and appears on the surface to be counter intuitive. We 
*could* send down batches of notifications and so each device could 
receive 3-4 notifications. This would mean that since we cannot predict 
the order of the notifications or even if they arrive, we would have to 
constantly be sending data back to our server telling us that the app is 
alive. We would have 2-3 times the number of connections coming back in 
which need to be processed very quickly. Our system is quite bursty, 
nothing happens for 3-4 minutes and then all hell breaks lose as we have 
to manage everything in around 30 secs. Also we are relying on every 
notification getting through we would be sending a lot of data which you 
have correctly identified as potentially an issue as well.

We also looked at sending our highly specific payloads, i.e. each user 
getting one message but that one message has 3-4 notifications in it. 
This would mean we have to process, generate and send thousands of 
individual messages. We know we can generate the individual messages 
quite quickly, but the the network connection costs are too high (so we 
believe). Simply connecting to the servers, opening the connection, 
sending and tearing the connection down could take a long time 
(minutes?) for 5,000 users. We don?t want to spread the connection 
time out, we want the data to get to the user ASAP.

If your views are different on the time take not do this, I?d be 
interested in hearing them as we believe the connection time would be 
too long. Since we don?t have 5,000 users we can?t easily test our 
hypothesis.

Rob

On 25 Nov 2015, at 10:50, Erik Jan de Wit wrote:

> Hi Rob,
>
> Like Matthias already told you on Android managing notifications and
> changing how they look is much simpler then on iOS. On iOS you can 
> cancel
> all the remote notifications, but not some.
>
> Corrine had this idea: send your notifications as 'background
> notifications' (e.g. 'content-available' flag set) then your app will 
> be
> notified, but nothing will show up in the Notification area. You can 
> use
> local notifications to create the notification in the notification 
> area,
> because these you can cancel. You decide how they show up and even 
> group
> them. The cordova plugin to create local notifications is called
> 'cordova-plugin-local-notifications' [1]
>
> So you will have to deal with the complexities of background 
> notifications
> for this to work, but to determine if the app is in the foreground 
> when the
> background notification arrives there is a boolean on the notification 
> to
> help [2]
>
> Although I must advise you sending large volumes of messages might not 
> be a
> great way to use push notifications, it's meant to inform the user 
> that
> something important has happened it should be personal and engage the
> users. Users could also opt to turn off the push notifications so you 
> can't
> use it to transfer data.
>
> Hope this helps
>
> [1] https://github.com/katzer/cordova-plugin-local-notifications
> [2]
> https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification
>
> On Wed, Nov 25, 2015 at 11:07 AM, Matthias Wessendorf 
> <matzew at apache.org>
> wrote:
>
>>
>>
>> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
>> rob.aerogear at robertwillett.com> wrote:
>>
>>> Hi,
>>>
>>> We?ve got the Unified Push Server working on the OpenShift 
>>> platform.
>>> No real issues once we?d understood the point of aliases.
>>>
>>> We can send notifications quite happily and see whats going on. We 
>>> use
>>> Perl for our backend servers and so we wrote a small Perl interface. 
>>> If
>>> anybody wants the code for the Perl interface let me know and 
>>> we?ll
>>> pass it on. We can?t claim a lot of credit for a simple piece of 
>>> code
>>> :)
>>>
>>
>> sure, I think that would be awesome, if you could publish it on 
>> github.
>> We will promote if for other perl users!
>>
>>
>>>
>>> Anyway, one of edge use-cases would be to delete notification or set 
>>> of
>>> notifications when the app is running but in the background on iOS.
>>>
>>> We want to do this as the user can receive a high number of
>>> notifications (> 10) when the app is in the background. 
>>> Notifications
>>> come in groups and provide traffic updates, so a user may get a new
>>> group of 3-4 traffic updates, this new group completely supersedes 
>>> ANY
>>> previous update. Our data is valuable when fresh and useless when 
>>> over
>>> 10 minutes old.
>>>
>>> Whilst we can simply ignore old notifications, UX testing has shown 
>>> the
>>> users don?t like having old notifications sitting round. We know 
>>> that
>>> the users can delete them individually or delete the lot from the
>>> notification drawer OR can simply bring the app out of the 
>>> background
>>> BUT they don?t like doing that.
>>>
>>> So what we want to do is delete old notifications, we were hoping 
>>> for
>>> the ability to call a JavaScript function with say a parameter to
>>> identify notifications by a group or something, but we could accept
>>> deleting the lot and inserting local notifications instead.
>>>
>>> We know that we can send content-available and have stuff pulled 
>>> from a
>>> server in the background. This option is quite difficult for us and 
>>> has
>>> some complexity identifying when the app is not started up. The 
>>> simplest
>>> option is delete some or all of the notifications.
>>>
>>> Does anybody know if this is possible or any other suggestions?
>>>
>>
>> I think that's an interesting idea. Erik Jan recently did an update 
>> for
>> message, on Cordova, to actually stack em:
>> https://github.com/aerogear/aerogear-cordova-push/pull/81
>>
>> Perhaps we could have a 'delete' feature too. Mind filing a JIRA 
>> against:
>> https://issues.jboss.org/projects/AGCORDOVA
>> (you need to have an account in order create tickets)
>>
>> Cheers!
>> Matthias
>>
>>
>>>
>>> Thanks
>>>
>>> Rob
>>> _______________________________________________
>>> 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-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> -- 
> Cheers,
>     Erik Jan
> _______________________________________________
> 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-users/attachments/20151125/8987908d/attachment-0001.html 

From matzew at apache.org  Wed Nov 25 08:02:10 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 25 Nov 2015 14:02:10 +0100
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <92114729-9182-456D-996D-F6A2BA055123@robertwillett.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
	<CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
	<CAO2B-fbfhaNFuZdg+4YYyei7A9vJ=+4Fr4+hQTO66xOTUF+gsg@mail.gmail.com>
	<92114729-9182-456D-996D-F6A2BA055123@robertwillett.com>
Message-ID: <CAAg5f2TMoubMEo0yG_S13a+Zhy_kD56B7Aip8=_9K9G86fmGSg@mail.gmail.com>

On Wed, Nov 25, 2015 at 1:30 PM, Rob Willett <rob.aerogear at robertwillett.com
> wrote:

> Erik,
>
> Thanks for the thoughtful reply.
>
> Great minds think alike :)
>
> We have already worked through this as an option and it is probably the
> likeliest way forward for us. Indeed your notes and ours are almost
> identical.
>
> You (or Corrine) have correctly identified the pitfalls regarding
> background and foreground. There is one other case and thats when the app
> is not actually started up. We still want to send them notifications (at
> least for a while) alerting them to traffic issues. After a day or so,
> we?ll throttle back these notifications but at least for a few hours or a
> day, we need to send them out. We can?t use the content-available flag as
> the app isn?t running (in either bg or fg) to handle the flag. So we have
> to try to work out if the app is ?alive? or not, if the app is not alive we
> send down full-fat notifications, this means no content-available flag and
> full information to be displayed in the notification drawer.
>
> Our potential solution has us send out a single silent notification to
> everybody who needs to be sent one. The device segmentation to determine
> who gets information is already done by us. The payload for the silent
> notification is actually empty and its used as a signalling mechanism. This
> tells the app when it is in the fg or bg to phone home and get a specific
> payload for that user. When the app contacts the backend database to
> retrieve the payload, we flag the app as alive and working.
>

when in background, on iOS you have a 30 second time window to fetch data
from the backend. I'd use that to issue local notification, these are
usually better to handle user interactions.


> If we send out a silent notification but never get a response to get a
> payload, then we flag the app as not started. After every batch of silent
> notifications are sent, 60 secs later, we then do a second cycle looking at
> whether the devices have NOT responded. If the app has not responded then
> we move to full notifications for that device and don?t use
> content-available. Once the user clicks on a notification and starts the
> app up, we can see that and we move them into the ?alive? state, so next
> time we send silent notifications.
>

that's nice trick, I'd like that "engine" on the UPS :-) haha


> The process diagram is a lot simpler than my explanation :)
>
> The other reason for sending a single silent notification with little
> information in and to get the app to respond to that single notification is
> quite subtle and appears on the surface to be counter intuitive. We
> *could* send down batches of notifications and so each device could
> receive 3-4 notifications. This would mean that since we cannot predict the
> order of the notifications or even if they arrive, we would have to
> constantly be sending data back to our server telling us that the app is
> alive. We would have 2-3 times the number of connections coming back in
> which need to be processed very quickly. Our system is quite bursty,
> nothing happens for 3-4 minutes and then all hell breaks lose as we have to
> manage everything in around 30 secs. Also we are relying on every
> notification getting through we would be sending a lot of data which you
> have correctly identified as potentially an issue as well.
>

what are you doing when push notifications are disabled?


> We also looked at sending our highly specific payloads, i.e. each user
> getting one message but that one message has 3-4 notifications in it. This
> would mean we have to process, generate and send thousands of individual
> messages. We know we can generate the individual messages quite quickly,
> but the the network connection costs are too high (so we believe). Simply
> connecting to the servers, opening the connection, sending and tearing the
> connection down could take a long time (minutes?) for 5,000 users. We don?t
> want to spread the connection time out, we want the data to get to the user
> ASAP.
>
yeah, I'd think so too, that sending a bunch of msgs might take sometime of
HTTP traffic. Regarding getting info out ASAP, for apps that are alive (in
fg), have you thought about using a TCP socket? I found this article
interesting http://blog.layer.com/how-we-leverage-ios-push-notifications/ -
worth a read.





> If your views are different on the time take not do this, I?d be
> interested in hearing them as we believe the connection time would be too
> long. Since we don?t have 5,000 users we can?t easily test our hypothesis.
>
> Rob
>
> On 25 Nov 2015, at 10:50, Erik Jan de Wit wrote:
>
> Hi Rob,
>
> Like Matthias already told you on Android managing notifications and
> changing how they look is much simpler then on iOS. On iOS you can cancel
> all the remote notifications, but not some.
>
> Corrine had this idea: send your notifications as 'background
> notifications' (e.g. 'content-available' flag set) then your app will be
> notified, but nothing will show up in the Notification area. You can use
> local notifications to create the notification in the notification area,
> because these you can cancel. You decide how they show up and even group
> them. The cordova plugin to create local notifications is called
> 'cordova-plugin-local-notifications' [1]
>
> So you will have to deal with the complexities of background notifications
> for this to work, but to determine if the app is in the foreground when the
> background notification arrives there is a boolean on the notification to
> help [2]
>
> Although I must advise you sending large volumes of messages might not be a
> great way to use push notifications, it's meant to inform the user that
> something important has happened it should be personal and engage the
> users. Users could also opt to turn off the push notifications so you can't
> use it to transfer data.
>
> Hope this helps
>
> [1] https://github.com/katzer/cordova-plugin-local-notifications
> [2]
>
> https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification
>
> On Wed, Nov 25, 2015 at 11:07 AM, Matthias Wessendorf matzew at apache.org
> wrote:
>
> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
> rob.aerogear at robertwillett.com> wrote:
>
> Hi,
>
> We?ve got the Unified Push Server working on the OpenShift platform.
> No real issues once we?d understood the point of aliases.
>
> We can send notifications quite happily and see whats going on. We use
> Perl for our backend servers and so we wrote a small Perl interface. If
> anybody wants the code for the Perl interface let me know and we?ll
> pass it on. We can?t claim a lot of credit for a simple piece of code
> :)
>
> sure, I think that would be awesome, if you could publish it on github.
> We will promote if for other perl users!
>
> Anyway, one of edge use-cases would be to delete notification or set of
> notifications when the app is running but in the background on iOS.
>
> We want to do this as the user can receive a high number of
> notifications (> 10) when the app is in the background. Notifications
> come in groups and provide traffic updates, so a user may get a new
> group of 3-4 traffic updates, this new group completely supersedes ANY
> previous update. Our data is valuable when fresh and useless when over
> 10 minutes old.
>
> Whilst we can simply ignore old notifications, UX testing has shown the
> users don?t like having old notifications sitting round. We know that
> the users can delete them individually or delete the lot from the
> notification drawer OR can simply bring the app out of the background
> BUT they don?t like doing that.
>
> So what we want to do is delete old notifications, we were hoping for
> the ability to call a JavaScript function with say a parameter to
> identify notifications by a group or something, but we could accept
> deleting the lot and inserting local notifications instead.
>
> We know that we can send content-available and have stuff pulled from a
> server in the background. This option is quite difficult for us and has
> some complexity identifying when the app is not started up. The simplest
> option is delete some or all of the notifications.
>
> Does anybody know if this is possible or any other suggestions?
>
> I think that's an interesting idea. Erik Jan recently did an update for
> message, on Cordova, to actually stack em:
> https://github.com/aerogear/aerogear-cordova-push/pull/81
>
> Perhaps we could have a 'delete' feature too. Mind filing a JIRA against:
> https://issues.jboss.org/projects/AGCORDOVA
> (you need to have an account in order create tickets)
>
> Cheers!
> Matthias
>
> Thanks
>
> Rob
> ------------------------------
>
> 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-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> --
> Cheers,
> Erik Jan
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
> _______________________________________________
> 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-users/attachments/20151125/ee5bf94a/attachment.html 

From matzew at apache.org  Wed Nov 25 08:05:00 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 25 Nov 2015 14:05:00 +0100
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <B064E062-68F1-4001-830B-8E9C8EF47506@robertwillett.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
	<CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
	<B064E062-68F1-4001-830B-8E9C8EF47506@robertwillett.com>
Message-ID: <CAAg5f2S2z19kuJzZ_ZaaS4PYWXRS4d2AJZcJJB7X1rM+SFoqig@mail.gmail.com>

Hi Rob

On Wed, Nov 25, 2015 at 1:00 PM, Rob Willett <rob.aerogear at robertwillett.com
> wrote:

> Matthias,
>
> Thanks for the prompt and helpful reply.
>
> We had a quick look at the stacking, as expected it seems to be for
> Android (which is no surprise at all). I am not an expert on iOS (or
> anything else) but as far as I know, stacking is impossible on iOS. We?re
> spending more and more time on getting the notifications right, its turned
> out to be significantly more complicated than we thought and one of the
> areas where we have two distinct lines of code in our Cordova app.
>
> I?ll raise JIRA for our ideas and let people ponder on that.
>

that would be awesome! We are happy to get anything into our SDKs and
servers, if useful for our users!


> In the last three weeks, we?ve tried four biggish vendors for Push
> notifications and we?ve had issues with all of them. Amazon, Parse, Urban
> Airship, OneSignal. Some are money issues (thats always the way), some are
> incredibly inflexible (Amazon), some don?t handle content-available, some
> don?t really support Cordova. Its been hardwork and we really, really want
> UPS to work for us. We?re tired of testing notifications on yet another
> system :)
>

Another benefit of the UPS is, that it's open-source. If you find the
server (or the SDKs) not efficient for a specific task, we all can together
work on it, and get it fixed


> I?ll put in on github but the code is pretty simple so I?ll put it here as
> well as we?re not big users off github and it might takes us a while to
> work it out. We?re rather old-school and like Emacs, Perl and dead simple
> stuff like that. We?ll try and work it out though
>

If you need help, let us know!


> Best wisher,
>
> Rob
>
> This is untested code as-is, we just pulled it straight out the testing
> file. We know it works in our system but I haven?t tested this simplified
> version. The github one will be tested though.
>
> #!/usr/bin/perl -w
>
> use strict;
> use warnings;
> use Net::Curl::Easy qw(/^CURLOPT_.*/);
> use JSON;
>
> sub SendAeroGearNotification
> {
>     my ($url , $username , $password , $config) = @_;
>     my $curl = Net::Curl::Easy->new;
>     my $json = JSON->new();
>     my $response_body;
>
>     my $json_string = $json->encode($config);
>
>     print "json string $json_string\n";
>
>     $curl->setopt( CURLOPT_URL, $url);
>     $curl->setopt( CURLOPT_SSL_VERIFYHOST , 0);
>     $curl->setopt( CURLOPT_SSL_VERIFYPEER , 0);
>
>     $curl->setopt( CURLOPT_USERPWD , "$username:$password");
>     $curl->setopt( CURLOPT_HTTPHEADER, ['Content-Type: application/json' ,
>                                         'Accept: application/json']);
>     $curl->setopt( CURLOPT_POST , 1);
>     $curl->setopt( CURLOPT_POSTFIELDS , $json_string);
>
>     $curl->setopt( CURLOPT_WRITEDATA , \$response_body);
>
>     $curl->perform;
>     print "AeroGear Reponse=".Dumper($response_body);
> }
>
>     my $notification_config = {
>                  variants => [ ?<<VARIANT ID>>? ] ,
>                  alias => [ ?alias1? , ?alias2? , ?alias3? ] ,
>                  ttl => 600 ,
>                  message => {
>                     alert => $contents ,
>                      'content-available' => JSON::true ,
>                      data => {
>                         key1 => value1 ,
>                         key2 => value2
>                      }
>                  }
>              };
>
>     SendAeroGearNotification("https://<<OPENSHIFT GEAR NAME>>.rhcloud.com/ag-push/rest/sender" ,
>                              ?<<USERNAME>>? ,
>                              ?<<PASSWORD>>? , $notification_config);
>
> On 25 Nov 2015, at 10:07, Matthias Wessendorf wrote:
>
> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
> rob.aerogear at robertwillett.com> wrote:
>
> Hi,
>
> We?ve got the Unified Push Server working on the OpenShift platform.
> No real issues once we?d understood the point of aliases.
>
> We can send notifications quite happily and see whats going on. We use
> Perl for our backend servers and so we wrote a small Perl interface. If
> anybody wants the code for the Perl interface let me know and we?ll
> pass it on. We can?t claim a lot of credit for a simple piece of code
> :)
>
> sure, I think that would be awesome, if you could publish it on github.
> We will promote if for other perl users!
>
> Anyway, one of edge use-cases would be to delete notification or set of
> notifications when the app is running but in the background on iOS.
>
> We want to do this as the user can receive a high number of
> notifications (> 10) when the app is in the background. Notifications
> come in groups and provide traffic updates, so a user may get a new
> group of 3-4 traffic updates, this new group completely supersedes ANY
> previous update. Our data is valuable when fresh and useless when over
> 10 minutes old.
>
> Whilst we can simply ignore old notifications, UX testing has shown the
> users don?t like having old notifications sitting round. We know that
> the users can delete them individually or delete the lot from the
> notification drawer OR can simply bring the app out of the background
> BUT they don?t like doing that.
>
> So what we want to do is delete old notifications, we were hoping for
> the ability to call a JavaScript function with say a parameter to
> identify notifications by a group or something, but we could accept
> deleting the lot and inserting local notifications instead.
>
> We know that we can send content-available and have stuff pulled from a
> server in the background. This option is quite difficult for us and has
> some complexity identifying when the app is not started up. The simplest
> option is delete some or all of the notifications.
>
> Does anybody know if this is possible or any other suggestions?
>
> I think that's an interesting idea. Erik Jan recently did an update for
> message, on Cordova, to actually stack em:
> https://github.com/aerogear/aerogear-cordova-push/pull/81
>
> Perhaps we could have a 'delete' feature too. Mind filing a JIRA against:
> https://issues.jboss.org/projects/AGCORDOVA
> (you need to have an account in order create tickets)
>
> Cheers!
> Matthias
>
>
> _______________________________________________
> 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-users/attachments/20151125/6acacd2f/attachment-0001.html 

From rob.aerogear at robertwillett.com  Wed Nov 25 08:17:29 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Wed, 25 Nov 2015 13:17:29 +0000
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <CAAg5f2TMoubMEo0yG_S13a+Zhy_kD56B7Aip8=_9K9G86fmGSg@mail.gmail.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
	<CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
	<CAO2B-fbfhaNFuZdg+4YYyei7A9vJ=+4Fr4+hQTO66xOTUF+gsg@mail.gmail.com>
	<92114729-9182-456D-996D-F6A2BA055123@robertwillett.com>
	<CAAg5f2TMoubMEo0yG_S13a+Zhy_kD56B7Aip8=_9K9G86fmGSg@mail.gmail.com>
Message-ID: <C3AE94C2-5BBE-4447-9A59-98AC1CDD13C9@robertwillett.com>

Matthias,

30 secs should be fine. We actually do very little processing, our data 
movements are small.

On 25 Nov 2015, at 13:02, Matthias Wessendorf wrote:

>>
>>
>> Our potential solution has us send out a single silent notification 
>> to
>> everybody who needs to be sent one. The device segmentation to 
>> determine
>> who gets information is already done by us. The payload for the 
>> silent
>> notification is actually empty and its used as a signalling 
>> mechanism. This
>> tells the app when it is in the fg or bg to phone home and get a 
>> specific
>> payload for that user. When the app contacts the backend database to
>> retrieve the payload, we flag the app as alive and working.
>>
>
> when in background, on iOS you have a 30 second time window to fetch 
> data
> from the backend. I'd use that to issue local notification, these are
> usually better to handle user interactions.
>
>> we move to full notifications for that device and don?t use
>> content-available. Once the user clicks on a notification and starts 
>> the
>> app up, we can see that and we move them into the ?alive? state, 
>> so next
>> time we send silent notifications.
>>
>
> that's nice trick, I'd like that "engine" on the UPS :-) haha

Thats todays job.

>> Our system is quite bursty,
>> nothing happens for 3-4 minutes and then all hell breaks lose as we 
>> have to
>> manage everything in around 30 secs. Also we are relying on every
>> notification getting through we would be sending a lot of data which 
>> you
>> have correctly identified as potentially an issue as well.
>>
>
> what are you doing when push notifications are disabled?

Can?t do anything if they are disabled. Our app checks at startup if 
they are disabled and requests that the user change to allow 
notifications. Apple doesn?t allow apps that require or need 
notifications. Our app works without notifications but if the user 
doesn?t want to receive them, nothing we can do. Can?t orce the user 
:)

>> We also looked at sending our highly specific payloads, i.e. each 
>> user
>> getting one message but that one message has 3-4 notifications in it. 
>> This
>> would mean we have to process, generate and send thousands of 
>> individual
>> messages. We know we can generate the individual messages quite 
>> quickly,
>> but the the network connection costs are too high (so we believe). 
>> Simply
>> connecting to the servers, opening the connection, sending and 
>> tearing the
>> connection down could take a long time (minutes?) for 5,000 users. We 
>> don?t
>> want to spread the connection time out, we want the data to get to 
>> the user
>> ASAP.
>>
> yeah, I'd think so too, that sending a bunch of msgs might take 
> sometime of
> HTTP traffic. Regarding getting info out ASAP, for apps that are alive 
> (in
> fg), have you thought about using a TCP socket? I found this article
> interesting 
> http://blog.layer.com/how-we-leverage-ios-push-notifications/ -
> worth a read.
>

We hadn?t thought of that as we have been so focussed on 
notifications. I?ve had a quick glance though the blog and it looks 
interesting. I can see that LayerKit has identified similar issues as we 
have already identified separately. The costs aren?t bad for what they 
provide, though you have to immediately stump up a credit card if you 
are in production. However they don?t appear to have a production 
Cordova plugin or JavaScript SDK (yet).  There appears to be a early 
access program though so we?ll look further into this.

Thanks for this, I have also raised a JIRA request, I can?t call it an 
issue as its not :)

Rob

>
>
>
>
>> If your views are different on the time take not do this, I?d be
>> interested in hearing them as we believe the connection time would be 
>> too
>> long. Since we don?t have 5,000 users we can?t easily test our 
>> hypothesis.
>>
>> Rob
>>
>> On 25 Nov 2015, at 10:50, Erik Jan de Wit wrote:
>>
>> Hi Rob,
>>
>> Like Matthias already told you on Android managing notifications and
>> changing how they look is much simpler then on iOS. On iOS you can 
>> cancel
>> all the remote notifications, but not some.
>>
>> Corrine had this idea: send your notifications as 'background
>> notifications' (e.g. 'content-available' flag set) then your app will 
>> be
>> notified, but nothing will show up in the Notification area. You can 
>> use
>> local notifications to create the notification in the notification 
>> area,
>> because these you can cancel. You decide how they show up and even 
>> group
>> them. The cordova plugin to create local notifications is called
>> 'cordova-plugin-local-notifications' [1]
>>
>> So you will have to deal with the complexities of background 
>> notifications
>> for this to work, but to determine if the app is in the foreground 
>> when the
>> background notification arrives there is a boolean on the 
>> notification to
>> help [2]
>>
>> Although I must advise you sending large volumes of messages might 
>> not be a
>> great way to use push notifications, it's meant to inform the user 
>> that
>> something important has happened it should be personal and engage the
>> users. Users could also opt to turn off the push notifications so you 
>> can't
>> use it to transfer data.
>>
>> Hope this helps
>>
>> [1] https://github.com/katzer/cordova-plugin-local-notifications
>> [2]
>>
>> https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification
>>
>> On Wed, Nov 25, 2015 at 11:07 AM, Matthias Wessendorf 
>> matzew at apache.org
>> wrote:
>>
>> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
>> rob.aerogear at robertwillett.com> wrote:
>>
>> Hi,
>>
>> We?ve got the Unified Push Server working on the OpenShift 
>> platform.
>> No real issues once we?d understood the point of aliases.
>>
>> We can send notifications quite happily and see whats going on. We 
>> use
>> Perl for our backend servers and so we wrote a small Perl interface. 
>> If
>> anybody wants the code for the Perl interface let me know and we?ll
>> pass it on. We can?t claim a lot of credit for a simple piece of 
>> code
>> :)
>>
>> sure, I think that would be awesome, if you could publish it on 
>> github.
>> We will promote if for other perl users!
>>
>> Anyway, one of edge use-cases would be to delete notification or set 
>> of
>> notifications when the app is running but in the background on iOS.
>>
>> We want to do this as the user can receive a high number of
>> notifications (> 10) when the app is in the background. Notifications
>> come in groups and provide traffic updates, so a user may get a new
>> group of 3-4 traffic updates, this new group completely supersedes 
>> ANY
>> previous update. Our data is valuable when fresh and useless when 
>> over
>> 10 minutes old.
>>
>> Whilst we can simply ignore old notifications, UX testing has shown 
>> the
>> users don?t like having old notifications sitting round. We know 
>> that
>> the users can delete them individually or delete the lot from the
>> notification drawer OR can simply bring the app out of the background
>> BUT they don?t like doing that.
>>
>> So what we want to do is delete old notifications, we were hoping for
>> the ability to call a JavaScript function with say a parameter to
>> identify notifications by a group or something, but we could accept
>> deleting the lot and inserting local notifications instead.
>>
>> We know that we can send content-available and have stuff pulled from 
>> a
>> server in the background. This option is quite difficult for us and 
>> has
>> some complexity identifying when the app is not started up. The 
>> simplest
>> option is delete some or all of the notifications.
>>
>> Does anybody know if this is possible or any other suggestions?
>>
>> I think that's an interesting idea. Erik Jan recently did an update 
>> for
>> message, on Cordova, to actually stack em:
>> https://github.com/aerogear/aerogear-cordova-push/pull/81
>>
>> Perhaps we could have a 'delete' feature too. Mind filing a JIRA 
>> against:
>> https://issues.jboss.org/projects/AGCORDOVA
>> (you need to have an account in order create tickets)
>>
>> Cheers!
>> Matthias
>>
>> Thanks
>>
>> Rob
>> ------------------------------
>>
>> 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-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> --
>> Cheers,
>> Erik Jan
>> ------------------------------
>>
>> Aerogear-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>> _______________________________________________
>> 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-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users


From edewit at redhat.com  Wed Nov 25 08:19:50 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Wed, 25 Nov 2015 14:19:50 +0100
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <92114729-9182-456D-996D-F6A2BA055123@robertwillett.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
	<CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
	<CAO2B-fbfhaNFuZdg+4YYyei7A9vJ=+4Fr4+hQTO66xOTUF+gsg@mail.gmail.com>
	<92114729-9182-456D-996D-F6A2BA055123@robertwillett.com>
Message-ID: <CAO2B-fYjZWSvFgXKs-GMGFw_0zyU=azmk8M-tOkLGUxZefEt+A@mail.gmail.com>

Hi Rob,

> You (or Corrine) have correctly identified the pitfalls regarding
> background and foreground. There is one other case and thats when the app
> is not actually started up. We still want to send them notifications (at
> least for a while) alerting them to traffic issues. After a day or so,
> we?ll throttle back these notifications but at least for a few hours or a
> day, we need to send them out. We can?t use the content-available flag as
> the app isn?t running (in either bg or fg) to handle the flag. So we have
> to try to work out if the app is ?alive? or not, if the app is not alive we
> send down full-fat notifications, this means no content-available flag and
> full information to be displayed in the notification drawer.
>
I think that when your app is not started the OS should start your app when
the notification arrives, so that it can handle it. It could be that the
app is not started because the device is low on power or there are some
heuristics as to how often the app is used, that might come in play as
well. But generally speaking a background notification should start the app
as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151125/4af09bc9/attachment.html 

From rob.aerogear at robertwillett.com  Wed Nov 25 08:27:42 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Wed, 25 Nov 2015 13:27:42 +0000
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <CAO2B-fYjZWSvFgXKs-GMGFw_0zyU=azmk8M-tOkLGUxZefEt+A@mail.gmail.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
	<CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
	<CAO2B-fbfhaNFuZdg+4YYyei7A9vJ=+4Fr4+hQTO66xOTUF+gsg@mail.gmail.com>
	<92114729-9182-456D-996D-F6A2BA055123@robertwillett.com>
	<CAO2B-fYjZWSvFgXKs-GMGFw_0zyU=azmk8M-tOkLGUxZefEt+A@mail.gmail.com>
Message-ID: <338E2FFB-6E3B-47E1-ABAC-575AC52285DB@robertwillett.com>

Erik,

Thats interesting. We hadn?t seen that happening at all. I 
specifically tested this yesterday when testing UPS.

We?ll test again

Rob

On 25 Nov 2015, at 13:19, Erik Jan de Wit wrote:

> Hi Rob,
>
>> You (or Corrine) have correctly identified the pitfalls regarding
>> background and foreground. There is one other case and thats when the 
>> app
>> is not actually started up. We still want to send them notifications 
>> (at
>> least for a while) alerting them to traffic issues. After a day or 
>> so,
>> we?ll throttle back these notifications but at least for a few 
>> hours or a
>> day, we need to send them out. We can?t use the content-available 
>> flag as
>> the app isn?t running (in either bg or fg) to handle the flag. So 
>> we have
>> to try to work out if the app is ?alive? or not, if the app is 
>> not alive we
>> send down full-fat notifications, this means no content-available 
>> flag and
>> full information to be displayed in the notification drawer.
>>
> I think that when your app is not started the OS should start your app 
> when
> the notification arrives, so that it can handle it. It could be that 
> the
> app is not started because the device is low on power or there are 
> some
> heuristics as to how often the app is used, that might come in play as
> well. But generally speaking a background notification should start 
> the app
> as well.
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users

From michael at 410labs.com  Wed Nov 25 12:32:36 2015
From: michael at 410labs.com (Michael Doo)
Date: Wed, 25 Nov 2015 12:32:36 -0500
Subject: [Aerogear-users] Cross-client auth support?
Message-ID: <CAJ5zYP8+rAmS_PMMePcMNguWV5-r+xQzM5R+CiiOibUEQm0tWw@mail.gmail.com>

Hello,

For the Aerogear iOS OAuth2 library, does it support cross-client
authorization as documented here:
https://developers.google.com/identity/protocols/CrossClientAuth? I have a
project configured in the Google Developers console with two OAuth2 client
IDs. I'd like to have my iOS app send a token request that contains both
client IDs (one in the client_id field and another in the audience field)
and receive a token that has the server_code field which I would then send
to my web app to get it's own refresh/access tokens. Example requests below.

Token request:
audience  <web app client ID>.apps.googleusercontent.com
client_id <iOS app client ID>.apps.googleusercontent.com
code  4/qmOAPMYafdJ1Qs14o6wK9Ok_p4bhkzjab72wwLtLg5A
grant_type  authorization_code
redirect_uri  com.googleusercontent.apps.<iOS app client ID>:/oauth2callback
verifier  81803532

Token response:
access_token  String
ya29.NgL_Yz4eECZQR0aHbrYh5_A06Rif_dQYxBLXXZLm5OQiInwKGcKI8Nd2PhxLNtV-XzoQ
token_type String  Bearer
expires_in  Integer 3600
refresh_token String
1/4aumZ1PQ00zk4xrc4W-xgjMIHA1GnDtpmc17Fopx9-RIgOrJDtdun6zK6XiATCKT
server_code String  4/qz-ClSW_wudBxj5H7cCFhaNDYQQrtcytAokQje_XKf0 <----
NEW!
id_token String  eyJhbGciOiJSUzI1NiIsImtpZCI6...

Best,
Michael Doo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151125/aadc1c93/attachment.html 

From rob.aerogear at robertwillett.com  Thu Nov 26 05:24:53 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Thu, 26 Nov 2015 10:24:53 +0000
Subject: [Aerogear-users] Trouble sending Android Push Notifications
Message-ID: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>

Hi,

We?ve got iOS notifications working well and so we thought we?d push 
our luck and get Android notifications up and running. We?ve had them 
working before with another plugin so it can?t be that difficult?.

We?ve followed the guide from here

https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troubleshooting

The Google web interface has changed but its still pretty much the same.

1. We?ve got and logged the Project Number (which is the Sender Id).

2. We?ve created a new server API key (is this the same as the GCM 
Messaging key?)

This appears to be all thats needed. We have an very old version of our 
app sitting in development in the Google Play Store but its never been 
released as we focussed on the iOS version. That used to linked to the 
GCM information but we have unlinked that now.

3. We have created a new variant on the UPS for Android. We create a 
name, description and where it asks for the Google Cloud Messaging Key 
we enter the Server API key we created in point 2. This is a bit we are 
unclear about, is the google Cloud Messaging Key the same as the Server 
API key we generated in Google Play services console? One of the things 
we noticed is that the example Google Cloud Messaging Key in the UPS 
dialogue box starts with a different few header bytes e.g. 5a44 whereas 
all the Server ApI keys start Alza. We are not experts on cryptography 
but we thought that *might* indicate a different type of key. It also 
might be nothing at all and Google has simply updated something.

4. We add in the Project number.

5. This creates the Android variant in the UPS dashboard. If we click on 
the variant we can see the expanded information showing the Server URL, 
the Variant ID and the Variant Secret.

6. This seems to work much the same as the iOS variant.

7. We then update our Cordova app and update the pushConfig field.

```
                 var aeroGearPushConfig = {
                     pushServerURL: 
"https://push-jambuster.rhcloud.com/ag-push/", // Checked that this 
matches the Android variant.
                     ios: {
                         variantID: ?XXXXX-TTTc-OOOO-RRRR-BBBHBHBH?, 
// Obscured
                         variantSecret: 
?JKJKJ-HHHH-PPOPIO-sdsds-1231232? // Obscured
                     } ,
                     android: {
                         senderID: ?XXXXXX? , // Changed to protect 
the innocent but checked that the senderID is the same as the Google 
Project Id
                         variantID: ?345345-345345-45345-xxxx-zzzzz? 
, // Changed but checked to make sure this is the Android VariantId
                         variantSecret: 
"9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to make 
sure this is the Android VariantSecret
                     } ,
                     sendMetricInfo: true,
                     alias: UUID // This is a unique string
                 };
```

We compile and run it on a real device, a Nexus 5. We create a unique 
alias to be sent to be sent as the alias. This is the UUID field

8. When we run the code and inspect the output in Chrome, the aeroGear 
Success Handler is called which we hope means success.

9. When we inspect the variant in the UPS dashboard, we can see that the 
a device with the right alias is created. The alias matches the alias we 
sent.

10. This all looks good. We have three real (i.e. non simulator) test 
devices in our UPS dashboard, two iOS devices and one Android device.

11. We click on the Send Push icon in the UPS dashboard to create some 
sample notifications. We send a simple test message to all variants. The 
two iPhones each get the test message and the Android phone doesn?t.

12. We click on the Dashboard icon in the UPS console, and then recent 
activity. We can see that the UPS server thinks it has sent the test 
message to the iOS and the Android variants. with no issues. We get 
alerts for the iOS pop up but nothing for the Android version.

```
Notification	Receivers	Status	Timestamp
  {"ipAddress?:?XX.YY.ZZ.216","clientIdentifier":"A...	3 
installations	Succeeded	26 Nov, 10:09:04, 2015
Request IP:	XX.YY.ZZ.216	Details
Message:	test11
Variants:	
Android Jambuster	Succeeded	1 installations
Jambuster Development	Succeeded	2 installations
```

13. The main UPS console doesn?t report any errors and it states that 
3 installations are registered. We?ve sent 657 notifications since 
yesterday trying to see what the problem is. We though that using the 
UPS console removed any issues with us creating the test message. Since 
we can see the iOS devices getting the test message, we are struggling 
to understand why the Android wouldn?t.

14. We?ve tried with the Android app running in the foreground, 
background and not running at all to see if that makes any difference 
and still nothing comes through.

15. If we look at the log files using roc tail, we can see that the 
messages get passed on. No error messages are reported.

```
2015/11/26 05:20:38,528 INFO  [PushNotificationSenderEndpoint] (EJB 
default - 7) Processing send request with &apos;[alert=Test12, 
criteria=[aliases=null, deviceTypes=null, categories=null, 
variants=null], time-to-live=-1]&apos; payload
2015/11/26 05:20:38,530 INFO  [PushNotificationSenderEndpoint] 
(http-/127.3.204.1:8080-5) Message submitted to PushNetworks for further 
processing
2015/11/26 05:20:38,533 INFO  [GCMPushNotificationSender] (EJB default - 
7) Sending payload for [1] devices to GCM
2015/11/26 05:20:38,590 INFO  [GCMPushNotificationSender] (EJB default - 
7) Message to GCM has been submitted
2015/11/26 05:20:38,726 INFO  [APNsPushNotificationSender] (EJB default 
- 7) Message to APNs has been submitted
```

Whilst it is impossible for people to debug our code and we don?t want 
people to, we?re struggling to understand what we could have done 
wrong. The fact we are getting iOS messages through whilst Android 
messages are failing (but with no error) is perplexing. We have rebuild 
the Server API kets in Google, deleted and rebuilt the Android variant 
but we?ve now hit a brick wall. We have a nagging feeling it is 
something to do with the GCM Server API key but everything reports OK.

Any and all suggestions gratefully received.

Thanks

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151126/5c9fa782/attachment-0001.html 

From rob.aerogear at robertwillett.com  Thu Nov 26 09:07:34 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Thu, 26 Nov 2015 14:07:34 +0000
Subject: [Aerogear-users] Unified Push Server - Anyway to delete
 notifications when in background?
In-Reply-To: <CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
References: <5942EF07-9F5D-41CA-AB5B-F469FB925BA6@robertwillett.com>
	<CAAg5f2QdNEWUmMtS8LvoSiOzi3qppRxgOdEbzzWfT7QmZiB3hA@mail.gmail.com>
Message-ID: <67B00429-C6A6-4FC7-AB28-1FED816BC363@robertwillett.com>

Matthias,

We think we?ve published the Perl sample on gitgub 
https://github.com/rwillett/AeroGear-UnifiedPush-Perl-Interface.

Please look and see if you can see it. Feel free to use it as you will.

Now we know how it works, we?ll upload other samples as we can an d 
that people may find useful.

Any changes please let me know.

Rob.

On 25 Nov 2015, at 10:07, Matthias Wessendorf wrote:

> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
> rob.aerogear at robertwillett.com> wrote:
>
>> Hi,
>>
>> We?ve got the Unified Push Server working on the OpenShift 
>> platform.
>> No real issues once we?d understood the point of aliases.
>>
>> We can send notifications quite happily and see whats going on. We 
>> use
>> Perl for our backend servers and so we wrote a small Perl interface. 
>> If
>> anybody wants the code for the Perl interface let me know and we?ll
>> pass it on. We can?t claim a lot of credit for a simple piece of 
>> code
>> :)
>>
>
> sure, I think that would be awesome, if you could publish it on 
> github.
> We will promote if for other perl users!
>
>
>>
>> Anyway, one of edge use-cases would be to delete notification or set 
>> of
>> notifications when the app is running but in the background on iOS.
>>
>> We want to do this as the user can receive a high number of
>> notifications (> 10) when the app is in the background. Notifications
>> come in groups and provide traffic updates, so a user may get a new
>> group of 3-4 traffic updates, this new group completely supersedes 
>> ANY
>> previous update. Our data is valuable when fresh and useless when 
>> over
>> 10 minutes old.
>>
>> Whilst we can simply ignore old notifications, UX testing has shown 
>> the
>> users don?t like having old notifications sitting round. We know 
>> that
>> the users can delete them individually or delete the lot from the
>> notification drawer OR can simply bring the app out of the background
>> BUT they don?t like doing that.
>>
>> So what we want to do is delete old notifications, we were hoping for
>> the ability to call a JavaScript function with say a parameter to
>> identify notifications by a group or something, but we could accept
>> deleting the lot and inserting local notifications instead.
>>
>> We know that we can send content-available and have stuff pulled from 
>> a
>> server in the background. This option is quite difficult for us and 
>> has
>> some complexity identifying when the app is not started up. The 
>> simplest
>> option is delete some or all of the notifications.
>>
>> Does anybody know if this is possible or any other suggestions?
>>
>
> I think that's an interesting idea. Erik Jan recently did an update 
> for
> message, on Cordova, to actually stack em:
> https://github.com/aerogear/aerogear-cordova-push/pull/81
>
> Perhaps we could have a 'delete' feature too. Mind filing a JIRA 
> against:
> https://issues.jboss.org/projects/AGCORDOVA
> (you need to have an account in order create tickets)
>
> Cheers!
> Matthias
>
>
>>
>> Thanks
>>
>> Rob
>> _______________________________________________
>> 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-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users

From dpassos at redhat.com  Thu Nov 26 09:27:28 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Thu, 26 Nov 2015 12:27:28 -0200
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
Message-ID: <CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>

It's seems to me some config problem. Are you sure you are using the
correct project number in "senderID" instead of project id?

http://monosnap.com/file/QmMAO1JQ4aWynfmatYat66vipsYxjr

On Thu, Nov 26, 2015 at 8:24 AM, Rob Willett <rob.aerogear at robertwillett.com
> wrote:

> Hi,
>
> We?ve got iOS notifications working well and so we thought we?d push our
> luck and get Android notifications up and running. We?ve had them working
> before with another plugin so it can?t be that difficult?.
>
> We?ve followed the guide from here
>
>
> https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troubleshooting
>
> The Google web interface has changed but its still pretty much the same.
>
>    1.
>
>    We?ve got and logged the Project Number (which is the Sender Id).
>    2.
>
>    We?ve created a new server API key (is this the same as the GCM
>    Messaging key?)
>
> This appears to be all thats needed. We have an very old version of our
> app sitting in development in the Google Play Store but its never been
> released as we focussed on the iOS version. That used to linked to the GCM
> information but we have unlinked that now.
>
>    1.
>
>    We have created a new variant on the UPS for Android. We create a
>    name, description and where it asks for the Google Cloud Messaging Key we
>    enter the Server API key we created in point 2. This is a bit we are
>    unclear about, is the google Cloud Messaging Key the same as the Server API
>    key we generated in Google Play services console? One of the things we
>    noticed is that the example Google Cloud Messaging Key in the UPS dialogue
>    box starts with a different few header bytes e.g. 5a44 whereas all the
>    Server ApI keys start Alza. We are not experts on cryptography but we
>    thought that *might* indicate a different type of key. It also might
>    be nothing at all and Google has simply updated something.
>    2.
>
>    We add in the Project number.
>    3.
>
>    This creates the Android variant in the UPS dashboard. If we click on
>    the variant we can see the expanded information showing the Server URL, the
>    Variant ID and the Variant Secret.
>    4.
>
>    This seems to work much the same as the iOS variant.
>    5.
>
>    We then update our Cordova app and update the pushConfig field.
>
>                 var aeroGearPushConfig = {
>                     pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", // Checked that this matches the Android variant.
>                     ios: {
>                         variantID: ?XXXXX-TTTc-OOOO-RRRR-BBBHBHBH?, // Obscured
>                         variantSecret: ?JKJKJ-HHHH-PPOPIO-sdsds-1231232? // Obscured
>                     } ,
>                     android: {
>                         senderID: ?XXXXXX? , // Changed to protect the innocent but checked that the senderID is the same as the Google Project Id
>                         variantID: ?345345-345345-45345-xxxx-zzzzz? , // Changed but checked to make sure this is the Android VariantId
>                         variantSecret: "9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to make sure this is the Android VariantSecret
>                     } ,
>                     sendMetricInfo: true,
>                     alias: UUID // This is a unique string
>                 };
>
> We compile and run it on a real device, a Nexus 5. We create a unique
> alias to be sent to be sent as the alias. This is the UUID field
>
>    1.
>
>    When we run the code and inspect the output in Chrome, the aeroGear
>    Success Handler is called which we hope means success.
>    2.
>
>    When we inspect the variant in the UPS dashboard, we can see that the
>    a device with the right alias is created. The alias matches the alias we
>    sent.
>    3.
>
>    This all looks good. We have three real (i.e. non simulator) test
>    devices in our UPS dashboard, two iOS devices and one Android device.
>    4.
>
>    We click on the Send Push icon in the UPS dashboard to create some
>    sample notifications. We send a simple test message to all variants. The
>    two iPhones each get the test message and the Android phone doesn?t.
>    5.
>
>    We click on the Dashboard icon in the UPS console, and then recent
>    activity. We can see that the UPS server thinks it has sent the test
>    message to the iOS and the Android variants. with no issues. We get alerts
>    for the iOS pop up but nothing for the Android version.
>
> Notification    Receivers    Status    Timestamp
>  {"ipAddress?:?XX.YY.ZZ.216","clientIdentifier":"A...    3 installations    Succeeded    26 Nov, 10:09:04, 2015
> Request IP:    XX.YY.ZZ.216    Details
> Message:    test11
> Variants:
> Android Jambuster    Succeeded    1 installations
> Jambuster Development    Succeeded    2 installations
>
>
>    1.
>
>    The main UPS console doesn?t report any errors and it states that 3
>    installations are registered. We?ve sent 657 notifications since yesterday
>    trying to see what the problem is. We though that using the UPS console
>    removed any issues with us creating the test message. Since we can see the
>    iOS devices getting the test message, we are struggling to understand why
>    the Android wouldn?t.
>    2.
>
>    We?ve tried with the Android app running in the foreground, background
>    and not running at all to see if that makes any difference and still
>    nothing comes through.
>    3.
>
>    If we look at the log files using roc tail, we can see that the
>    messages get passed on. No error messages are reported.
>
> 2015/11/26 05:20:38,528 INFO  [PushNotificationSenderEndpoint] (EJB default - 7) Processing send request with &apos;[alert=Test12, criteria=[aliases=null, deviceTypes=null, categories=null, variants=null], time-to-live=-1]&apos; payload
> 2015/11/26 05:20:38,530 INFO  [PushNotificationSenderEndpoint] (http-/127.3.204.1:8080-5) Message submitted to PushNetworks for further processing
> 2015/11/26 05:20:38,533 INFO  [GCMPushNotificationSender] (EJB default - 7) Sending payload for [1] devices to GCM
> 2015/11/26 05:20:38,590 INFO  [GCMPushNotificationSender] (EJB default - 7) Message to GCM has been submitted
> 2015/11/26 05:20:38,726 INFO  [APNsPushNotificationSender] (EJB default - 7) Message to APNs has been submitted
>
> Whilst it is impossible for people to debug our code and we don?t want
> people to, we?re struggling to understand what we could have done wrong.
> The fact we are getting iOS messages through whilst Android messages are
> failing (but with no error) is perplexing. We have rebuild the Server API
> kets in Google, deleted and rebuilt the Android variant but we?ve now hit a
> brick wall. We have a nagging feeling it is something to do with the GCM
> Server API key but everything reports OK.
>
> Any and all suggestions gratefully received.
>
> Thanks
>
> Rob
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>


-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151126/f1403361/attachment.html 

From matzew at apache.org  Thu Nov 26 09:32:48 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 26 Nov 2015 15:32:48 +0100
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
Message-ID: <CAAg5f2QNtzG6EdgB7gNaGfd70MrKgJeBqhJLJhBbWY6=GjWsEg@mail.gmail.com>

On Thu, Nov 26, 2015 at 11:24 AM, Rob Willett <
rob.aerogear at robertwillett.com> wrote:

> Hi,
>
> We?ve got iOS notifications working well and so we thought we?d push our
> luck and get Android notifications up and running. We?ve had them working
> before with another plugin so it can?t be that difficult?.
>
> We?ve followed the guide from here
>
>
> https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troubleshooting
>
> The Google web interface has changed but its still pretty much the same.
>

A member of our docs team is already on it:
https://issues.jboss.org/browse/AGPUSH-1536

-M



>
>    1.
>
>    We?ve got and logged the Project Number (which is the Sender Id).
>    2.
>
>    We?ve created a new server API key (is this the same as the GCM
>    Messaging key?)
>
> This appears to be all thats needed. We have an very old version of our
> app sitting in development in the Google Play Store but its never been
> released as we focussed on the iOS version. That used to linked to the GCM
> information but we have unlinked that now.
>
>    1.
>
>    We have created a new variant on the UPS for Android. We create a
>    name, description and where it asks for the Google Cloud Messaging Key we
>    enter the Server API key we created in point 2. This is a bit we are
>    unclear about, is the google Cloud Messaging Key the same as the Server API
>    key we generated in Google Play services console? One of the things we
>    noticed is that the example Google Cloud Messaging Key in the UPS dialogue
>    box starts with a different few header bytes e.g. 5a44 whereas all the
>    Server ApI keys start Alza. We are not experts on cryptography but we
>    thought that *might* indicate a different type of key. It also might
>    be nothing at all and Google has simply updated something.
>    2.
>
>    We add in the Project number.
>    3.
>
>    This creates the Android variant in the UPS dashboard. If we click on
>    the variant we can see the expanded information showing the Server URL, the
>    Variant ID and the Variant Secret.
>    4.
>
>    This seems to work much the same as the iOS variant.
>    5.
>
>    We then update our Cordova app and update the pushConfig field.
>
>                 var aeroGearPushConfig = {
>                     pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", // Checked that this matches the Android variant.
>                     ios: {
>                         variantID: ?XXXXX-TTTc-OOOO-RRRR-BBBHBHBH?, // Obscured
>                         variantSecret: ?JKJKJ-HHHH-PPOPIO-sdsds-1231232? // Obscured
>                     } ,
>                     android: {
>                         senderID: ?XXXXXX? , // Changed to protect the innocent but checked that the senderID is the same as the Google Project Id
>                         variantID: ?345345-345345-45345-xxxx-zzzzz? , // Changed but checked to make sure this is the Android VariantId
>                         variantSecret: "9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to make sure this is the Android VariantSecret
>                     } ,
>                     sendMetricInfo: true,
>                     alias: UUID // This is a unique string
>                 };
>
> We compile and run it on a real device, a Nexus 5. We create a unique
> alias to be sent to be sent as the alias. This is the UUID field
>
>    1.
>
>    When we run the code and inspect the output in Chrome, the aeroGear
>    Success Handler is called which we hope means success.
>    2.
>
>    When we inspect the variant in the UPS dashboard, we can see that the
>    a device with the right alias is created. The alias matches the alias we
>    sent.
>    3.
>
>    This all looks good. We have three real (i.e. non simulator) test
>    devices in our UPS dashboard, two iOS devices and one Android device.
>    4.
>
>    We click on the Send Push icon in the UPS dashboard to create some
>    sample notifications. We send a simple test message to all variants. The
>    two iPhones each get the test message and the Android phone doesn?t.
>    5.
>
>    We click on the Dashboard icon in the UPS console, and then recent
>    activity. We can see that the UPS server thinks it has sent the test
>    message to the iOS and the Android variants. with no issues. We get alerts
>    for the iOS pop up but nothing for the Android version.
>
> Notification    Receivers    Status    Timestamp
>  {"ipAddress?:?XX.YY.ZZ.216","clientIdentifier":"A...    3 installations    Succeeded    26 Nov, 10:09:04, 2015
> Request IP:    XX.YY.ZZ.216    Details
> Message:    test11
> Variants:
> Android Jambuster    Succeeded    1 installations
> Jambuster Development    Succeeded    2 installations
>
>
>    1.
>
>    The main UPS console doesn?t report any errors and it states that 3
>    installations are registered. We?ve sent 657 notifications since yesterday
>    trying to see what the problem is. We though that using the UPS console
>    removed any issues with us creating the test message. Since we can see the
>    iOS devices getting the test message, we are struggling to understand why
>    the Android wouldn?t.
>    2.
>
>    We?ve tried with the Android app running in the foreground, background
>    and not running at all to see if that makes any difference and still
>    nothing comes through.
>    3.
>
>    If we look at the log files using roc tail, we can see that the
>    messages get passed on. No error messages are reported.
>
> 2015/11/26 05:20:38,528 INFO  [PushNotificationSenderEndpoint] (EJB default - 7) Processing send request with &apos;[alert=Test12, criteria=[aliases=null, deviceTypes=null, categories=null, variants=null], time-to-live=-1]&apos; payload
> 2015/11/26 05:20:38,530 INFO  [PushNotificationSenderEndpoint] (http-/127.3.204.1:8080-5) Message submitted to PushNetworks for further processing
> 2015/11/26 05:20:38,533 INFO  [GCMPushNotificationSender] (EJB default - 7) Sending payload for [1] devices to GCM
> 2015/11/26 05:20:38,590 INFO  [GCMPushNotificationSender] (EJB default - 7) Message to GCM has been submitted
> 2015/11/26 05:20:38,726 INFO  [APNsPushNotificationSender] (EJB default - 7) Message to APNs has been submitted
>
> Whilst it is impossible for people to debug our code and we don?t want
> people to, we?re struggling to understand what we could have done wrong.
> The fact we are getting iOS messages through whilst Android messages are
> failing (but with no error) is perplexing. We have rebuild the Server API
> kets in Google, deleted and rebuilt the Android variant but we?ve now hit a
> brick wall. We have a nagging feeling it is something to do with the GCM
> Server API key but everything reports OK.
>
> Any and all suggestions gratefully received.
>
> Thanks
>
> Rob
>
> _______________________________________________
> 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-users/attachments/20151126/ad7d74af/attachment-0001.html 

From scm.blanc at gmail.com  Thu Nov 26 09:33:27 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Thu, 26 Nov 2015 15:33:27 +0100
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
Message-ID: <CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>

Hi Rob,

Maybe obvious but just to be sure :  have you enabled "Google Cloud
Messaging for Android" API ?

You also mention that you are using an old project, I have seen before
issues with my old projects, could you create a new google project to see
if that helps ?

Last point : have you checked in the Android logs (logcat) that the message
really dies not arrive ?



On Thu, Nov 26, 2015 at 3:27 PM, Daniel Passos <dpassos at redhat.com> wrote:

> It's seems to me some config problem. Are you sure you are using the
> correct project number in "senderID" instead of project id?
>
> http://monosnap.com/file/QmMAO1JQ4aWynfmatYat66vipsYxjr
>
> On Thu, Nov 26, 2015 at 8:24 AM, Rob Willett <
> rob.aerogear at robertwillett.com> wrote:
>
>> Hi,
>>
>> We?ve got iOS notifications working well and so we thought we?d push our
>> luck and get Android notifications up and running. We?ve had them working
>> before with another plugin so it can?t be that difficult?.
>>
>> We?ve followed the guide from here
>>
>>
>> https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troubleshooting
>>
>> The Google web interface has changed but its still pretty much the same.
>>
>>    1.
>>
>>    We?ve got and logged the Project Number (which is the Sender Id).
>>    2.
>>
>>    We?ve created a new server API key (is this the same as the GCM
>>    Messaging key?)
>>
>> This appears to be all thats needed. We have an very old version of our
>> app sitting in development in the Google Play Store but its never been
>> released as we focussed on the iOS version. That used to linked to the GCM
>> information but we have unlinked that now.
>>
>>    1.
>>
>>    We have created a new variant on the UPS for Android. We create a
>>    name, description and where it asks for the Google Cloud Messaging Key we
>>    enter the Server API key we created in point 2. This is a bit we are
>>    unclear about, is the google Cloud Messaging Key the same as the Server API
>>    key we generated in Google Play services console? One of the things we
>>    noticed is that the example Google Cloud Messaging Key in the UPS dialogue
>>    box starts with a different few header bytes e.g. 5a44 whereas all the
>>    Server ApI keys start Alza. We are not experts on cryptography but we
>>    thought that *might* indicate a different type of key. It also might
>>    be nothing at all and Google has simply updated something.
>>    2.
>>
>>    We add in the Project number.
>>    3.
>>
>>    This creates the Android variant in the UPS dashboard. If we click on
>>    the variant we can see the expanded information showing the Server URL, the
>>    Variant ID and the Variant Secret.
>>    4.
>>
>>    This seems to work much the same as the iOS variant.
>>    5.
>>
>>    We then update our Cordova app and update the pushConfig field.
>>
>>                 var aeroGearPushConfig = {
>>                     pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", // Checked that this matches the Android variant.
>>                     ios: {
>>                         variantID: ?XXXXX-TTTc-OOOO-RRRR-BBBHBHBH?, // Obscured
>>                         variantSecret: ?JKJKJ-HHHH-PPOPIO-sdsds-1231232? // Obscured
>>                     } ,
>>                     android: {
>>                         senderID: ?XXXXXX? , // Changed to protect the innocent but checked that the senderID is the same as the Google Project Id
>>                         variantID: ?345345-345345-45345-xxxx-zzzzz? , // Changed but checked to make sure this is the Android VariantId
>>                         variantSecret: "9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to make sure this is the Android VariantSecret
>>                     } ,
>>                     sendMetricInfo: true,
>>                     alias: UUID // This is a unique string
>>                 };
>>
>> We compile and run it on a real device, a Nexus 5. We create a unique
>> alias to be sent to be sent as the alias. This is the UUID field
>>
>>    1.
>>
>>    When we run the code and inspect the output in Chrome, the aeroGear
>>    Success Handler is called which we hope means success.
>>    2.
>>
>>    When we inspect the variant in the UPS dashboard, we can see that the
>>    a device with the right alias is created. The alias matches the alias we
>>    sent.
>>    3.
>>
>>    This all looks good. We have three real (i.e. non simulator) test
>>    devices in our UPS dashboard, two iOS devices and one Android device.
>>    4.
>>
>>    We click on the Send Push icon in the UPS dashboard to create some
>>    sample notifications. We send a simple test message to all variants. The
>>    two iPhones each get the test message and the Android phone doesn?t.
>>    5.
>>
>>    We click on the Dashboard icon in the UPS console, and then recent
>>    activity. We can see that the UPS server thinks it has sent the test
>>    message to the iOS and the Android variants. with no issues. We get alerts
>>    for the iOS pop up but nothing for the Android version.
>>
>> Notification    Receivers    Status    Timestamp
>>  {"ipAddress?:?XX.YY.ZZ.216","clientIdentifier":"A...    3 installations    Succeeded    26 Nov, 10:09:04, 2015
>> Request IP:    XX.YY.ZZ.216    Details
>> Message:    test11
>> Variants:
>> Android Jambuster    Succeeded    1 installations
>> Jambuster Development    Succeeded    2 installations
>>
>>
>>    1.
>>
>>    The main UPS console doesn?t report any errors and it states that 3
>>    installations are registered. We?ve sent 657 notifications since yesterday
>>    trying to see what the problem is. We though that using the UPS console
>>    removed any issues with us creating the test message. Since we can see the
>>    iOS devices getting the test message, we are struggling to understand why
>>    the Android wouldn?t.
>>    2.
>>
>>    We?ve tried with the Android app running in the foreground,
>>    background and not running at all to see if that makes any difference and
>>    still nothing comes through.
>>    3.
>>
>>    If we look at the log files using roc tail, we can see that the
>>    messages get passed on. No error messages are reported.
>>
>> 2015/11/26 05:20:38,528 INFO  [PushNotificationSenderEndpoint] (EJB default - 7) Processing send request with &apos;[alert=Test12, criteria=[aliases=null, deviceTypes=null, categories=null, variants=null], time-to-live=-1]&apos; payload
>> 2015/11/26 05:20:38,530 INFO  [PushNotificationSenderEndpoint] (http-/127.3.204.1:8080-5) Message submitted to PushNetworks for further processing
>> 2015/11/26 05:20:38,533 INFO  [GCMPushNotificationSender] (EJB default - 7) Sending payload for [1] devices to GCM
>> 2015/11/26 05:20:38,590 INFO  [GCMPushNotificationSender] (EJB default - 7) Message to GCM has been submitted
>> 2015/11/26 05:20:38,726 INFO  [APNsPushNotificationSender] (EJB default - 7) Message to APNs has been submitted
>>
>> Whilst it is impossible for people to debug our code and we don?t want
>> people to, we?re struggling to understand what we could have done wrong.
>> The fact we are getting iOS messages through whilst Android messages are
>> failing (but with no error) is perplexing. We have rebuild the Server API
>> kets in Google, deleted and rebuilt the Android variant but we?ve now hit a
>> brick wall. We have a nagging feeling it is something to do with the GCM
>> Server API key but everything reports OK.
>>
>> Any and all suggestions gratefully received.
>>
>> Thanks
>>
>> Rob
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> --
> -- Passos
>
> _______________________________________________
> 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-users/attachments/20151126/d462c07e/attachment.html 

From rob.aerogear at robertwillett.com  Thu Nov 26 09:38:18 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Thu, 26 Nov 2015 14:38:18 +0000
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
Message-ID: <E6446965-1700-4D5C-A91A-994B1745D8BE@robertwillett.com>

Daniel,

Thanks for the reply and the diagram.

We are definitely sending the right project number.

and here?s the same thing in the UPS console. We?ve obscured the 
Google Cloud messaging Key. Thats the one thing we are not certain on. 
Do you mind saying if your GCM Key starts 5xxxxx or AlZa as ours does. 
The UPS docs are little unclear here.


Rob




On 26 Nov 2015, at 14:27, Daniel Passos wrote:

> It's seems to me some config problem. Are you sure you are using the
> correct project number in "senderID" instead of project id?
>
> http://monosnap.com/file/QmMAO1JQ4aWynfmatYat66vipsYxjr
>
> On Thu, Nov 26, 2015 at 8:24 AM, Rob Willett 
> <rob.aerogear at robertwillett.com
>> wrote:
>
>> Hi,
>>
>> We?ve got iOS notifications working well and so we thought we?d 
>> push our
>> luck and get Android notifications up and running. We?ve had them 
>> working
>> before with another plugin so it can?t be that difficult?.
>>
>> We?ve followed the guide from here
>>
>>
>> https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troubleshooting
>>
>> The Google web interface has changed but its still pretty much the 
>> same.
>>
>> 1.
>>
>> We?ve got and logged the Project Number (which is the Sender Id).
>> 2.
>>
>> We?ve created a new server API key (is this the same as the GCM
>> Messaging key?)
>>
>> This appears to be all thats needed. We have an very old version of 
>> our
>> app sitting in development in the Google Play Store but its never 
>> been
>> released as we focussed on the iOS version. That used to linked to 
>> the GCM
>> information but we have unlinked that now.
>>
>> 1.
>>
>> We have created a new variant on the UPS for Android. We create a
>> name, description and where it asks for the Google Cloud Messaging 
>> Key we
>> enter the Server API key we created in point 2. This is a bit we are
>> unclear about, is the google Cloud Messaging Key the same as the 
>> Server API
>> key we generated in Google Play services console? One of the things 
>> we
>> noticed is that the example Google Cloud Messaging Key in the UPS 
>> dialogue
>> box starts with a different few header bytes e.g. 5a44 whereas all 
>> the
>> Server ApI keys start Alza. We are not experts on cryptography but we
>> thought that *might* indicate a different type of key. It also might
>> be nothing at all and Google has simply updated something.
>> 2.
>>
>> We add in the Project number.
>> 3.
>>
>> This creates the Android variant in the UPS dashboard. If we click on
>> the variant we can see the expanded information showing the Server 
>> URL, the
>> Variant ID and the Variant Secret.
>> 4.
>>
>> This seems to work much the same as the iOS variant.
>> 5.
>>
>> We then update our Cordova app and update the pushConfig field.
>>
>>              var aeroGearPushConfig = {
>>                  pushServerURL: 
>> "https://push-jambuster.rhcloud.com/ag-push/", // Checked that this 
>> matches the Android variant.
>>                  ios: {
>>                      variantID: ?XXXXX-TTTc-OOOO-RRRR-BBBHBHBH?, 
>> // Obscured
>>                      variantSecret: 
>> ?JKJKJ-HHHH-PPOPIO-sdsds-1231232? // Obscured
>>                  } ,
>>                  android: {
>>                      senderID: ?XXXXXX? , // Changed to protect 
>> the innocent but checked that the senderID is the same as the Google 
>> Project Id
>>                      variantID: ?345345-345345-45345-xxxx-zzzzz? 
>> , // Changed but checked to make sure this is the Android VariantId
>>                      variantSecret: 
>> "9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to make 
>> sure this is the Android VariantSecret
>>                  } ,
>>                  sendMetricInfo: true,
>>                  alias: UUID // This is a unique string
>>              };
>>
>> We compile and run it on a real device, a Nexus 5. We create a unique
>> alias to be sent to be sent as the alias. This is the UUID field
>>
>> 1.
>>
>> When we run the code and inspect the output in Chrome, the aeroGear
>> Success Handler is called which we hope means success.
>> 2.
>>
>> When we inspect the variant in the UPS dashboard, we can see that the
>> a device with the right alias is created. The alias matches the alias 
>> we
>> sent.
>> 3.
>>
>> This all looks good. We have three real (i.e. non simulator) test
>> devices in our UPS dashboard, two iOS devices and one Android device.
>> 4.
>>
>> We click on the Send Push icon in the UPS dashboard to create some
>> sample notifications. We send a simple test message to all variants. 
>> The
>> two iPhones each get the test message and the Android phone 
>> doesn?t.
>> 5.
>>
>> We click on the Dashboard icon in the UPS console, and then recent
>> activity. We can see that the UPS server thinks it has sent the test
>> message to the iOS and the Android variants. with no issues. We get 
>> alerts
>> for the iOS pop up but nothing for the Android version.
>>
>> Notification    Receivers    Status    Timestamp
>> {"ipAddress?:?XX.YY.ZZ.216","clientIdentifier":"A...    3 
>> installations    Succeeded    26 Nov, 10:09:04, 2015
>> Request IP:    XX.YY.ZZ.216    Details
>> Message:    test11
>> Variants:
>> Android Jambuster    Succeeded    1 installations
>> Jambuster Development    Succeeded    2 installations
>>
>>
>> 1.
>>
>> The main UPS console doesn?t report any errors and it states that 3
>> installations are registered. We?ve sent 657 notifications since 
>> yesterday
>> trying to see what the problem is. We though that using the UPS 
>> console
>> removed any issues with us creating the test message. Since we can 
>> see the
>> iOS devices getting the test message, we are struggling to understand 
>> why
>> the Android wouldn?t.
>> 2.
>>
>> We?ve tried with the Android app running in the foreground, 
>> background
>> and not running at all to see if that makes any difference and still
>> nothing comes through.
>> 3.
>>
>> If we look at the log files using roc tail, we can see that the
>> messages get passed on. No error messages are reported.
>>
>> 2015/11/26 05:20:38,528 INFO  [PushNotificationSenderEndpoint] (EJB 
>> default - 7) Processing send request with &apos;[alert=Test12, 
>> criteria=[aliases=null, deviceTypes=null, categories=null, 
>> variants=null], time-to-live=-1]&apos; payload
>> 2015/11/26 05:20:38,530 INFO  [PushNotificationSenderEndpoint] 
>> (http-/127.3.204.1:8080-5) Message submitted to PushNetworks for 
>> further processing
>> 2015/11/26 05:20:38,533 INFO  [GCMPushNotificationSender] (EJB 
>> default - 7) Sending payload for [1] devices to GCM
>> 2015/11/26 05:20:38,590 INFO  [GCMPushNotificationSender] (EJB 
>> default - 7) Message to GCM has been submitted
>> 2015/11/26 05:20:38,726 INFO  [APNsPushNotificationSender] (EJB 
>> default - 7) Message to APNs has been submitted
>>
>> Whilst it is impossible for people to debug our code and we don?t 
>> want
>> people to, we?re struggling to understand what we could have done 
>> wrong.
>> The fact we are getting iOS messages through whilst Android messages 
>> are
>> failing (but with no error) is perplexing. We have rebuild the Server 
>> API
>> kets in Google, deleted and rebuilt the Android variant but we?ve 
>> now hit a
>> brick wall. We have a nagging feeling it is something to do with the 
>> GCM
>> Server API key but everything reports OK.
>>
>> Any and all suggestions gratefully received.
>>
>> Thanks
>>
>> Rob
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> -- 
> -- Passos
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2015-11-26 at 14.31.10.png
Type: image/png
Size: 14645 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-users/attachments/20151126/1a9725a4/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2015-11-26 at 14.36.39.png
Type: image/png
Size: 45285 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-users/attachments/20151126/1a9725a4/attachment-0003.png 

From rob.aerogear at robertwillett.com  Thu Nov 26 09:41:28 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Thu, 26 Nov 2015 14:41:28 +0000
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
Message-ID: <E27F03A2-0BD6-4741-A157-E1D5C2A728E1@robertwillett.com>

Sebastian

Excellent questions to which we have no answers :)

Let us work through them and we?ll come back to you here.

Rob

On 26 Nov 2015, at 14:33, Sebastien Blanc wrote:

> Hi Rob,
>
> Maybe obvious but just to be sure :  have you enabled "Google Cloud
> Messaging for Android" API ?
>
> You also mention that you are using an old project, I have seen before
> issues with my old projects, could you create a new google project to 
> see
> if that helps ?
>
> Last point : have you checked in the Android logs (logcat) that the 
> message
> really dies not arrive ?
>
>
>
> On Thu, Nov 26, 2015 at 3:27 PM, Daniel Passos <dpassos at redhat.com> 
> wrote:
>
>> It's seems to me some config problem. Are you sure you are using the
>> correct project number in "senderID" instead of project id?
>>
>> http://monosnap.com/file/QmMAO1JQ4aWynfmatYat66vipsYxjr
>>
>> On Thu, Nov 26, 2015 at 8:24 AM, Rob Willett <
>> rob.aerogear at robertwillett.com> wrote:
>>
>>> Hi,
>>>
>>> We?ve got iOS notifications working well and so we thought we?d 
>>> push our
>>> luck and get Android notifications up and running. We?ve had them 
>>> working
>>> before with another plugin so it can?t be that difficult?.
>>>
>>> We?ve followed the guide from here
>>>
>>>
>>> https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troubleshooting
>>>
>>> The Google web interface has changed but its still pretty much the 
>>> same.
>>>
>>> 1.
>>>
>>> We?ve got and logged the Project Number (which is the Sender Id).
>>> 2.
>>>
>>> We?ve created a new server API key (is this the same as the GCM
>>> Messaging key?)
>>>
>>> This appears to be all thats needed. We have an very old version of 
>>> our
>>> app sitting in development in the Google Play Store but its never 
>>> been
>>> released as we focussed on the iOS version. That used to linked to 
>>> the GCM
>>> information but we have unlinked that now.
>>>
>>> 1.
>>>
>>> We have created a new variant on the UPS for Android. We create a
>>> name, description and where it asks for the Google Cloud Messaging 
>>> Key we
>>> enter the Server API key we created in point 2. This is a bit we are
>>> unclear about, is the google Cloud Messaging Key the same as the 
>>> Server API
>>> key we generated in Google Play services console? One of the things 
>>> we
>>> noticed is that the example Google Cloud Messaging Key in the UPS 
>>> dialogue
>>> box starts with a different few header bytes e.g. 5a44 whereas all 
>>> the
>>> Server ApI keys start Alza. We are not experts on cryptography but 
>>> we
>>> thought that *might* indicate a different type of key. It also might
>>> be nothing at all and Google has simply updated something.
>>> 2.
>>>
>>> We add in the Project number.
>>> 3.
>>>
>>> This creates the Android variant in the UPS dashboard. If we click 
>>> on
>>> the variant we can see the expanded information showing the Server 
>>> URL, the
>>> Variant ID and the Variant Secret.
>>> 4.
>>>
>>> This seems to work much the same as the iOS variant.
>>> 5.
>>>
>>> We then update our Cordova app and update the pushConfig field.
>>>
>>>              var aeroGearPushConfig = {
>>>                  pushServerURL: 
>>> "https://push-jambuster.rhcloud.com/ag-push/", // Checked that this 
>>> matches the Android variant.
>>>                  ios: {
>>>                      variantID: ?XXXXX-TTTc-OOOO-RRRR-BBBHBHBH?, 
>>> // Obscured
>>>                      variantSecret: 
>>> ?JKJKJ-HHHH-PPOPIO-sdsds-1231232? // Obscured
>>>                  } ,
>>>                  android: {
>>>                      senderID: ?XXXXXX? , // Changed to protect 
>>> the innocent but checked that the senderID is the same as the Google 
>>> Project Id
>>>                      variantID: ?345345-345345-45345-xxxx-zzzzz? 
>>> , // Changed but checked to make sure this is the Android VariantId
>>>                      variantSecret: 
>>> "9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to 
>>> make sure this is the Android VariantSecret
>>>                  } ,
>>>                  sendMetricInfo: true,
>>>                  alias: UUID // This is a unique string
>>>              };
>>>
>>> We compile and run it on a real device, a Nexus 5. We create a 
>>> unique
>>> alias to be sent to be sent as the alias. This is the UUID field
>>>
>>> 1.
>>>
>>> When we run the code and inspect the output in Chrome, the aeroGear
>>> Success Handler is called which we hope means success.
>>> 2.
>>>
>>> When we inspect the variant in the UPS dashboard, we can see that 
>>> the
>>> a device with the right alias is created. The alias matches the 
>>> alias we
>>> sent.
>>> 3.
>>>
>>> This all looks good. We have three real (i.e. non simulator) test
>>> devices in our UPS dashboard, two iOS devices and one Android 
>>> device.
>>> 4.
>>>
>>> We click on the Send Push icon in the UPS dashboard to create some
>>> sample notifications. We send a simple test message to all variants. 
>>> The
>>> two iPhones each get the test message and the Android phone 
>>> doesn?t.
>>> 5.
>>>
>>> We click on the Dashboard icon in the UPS console, and then recent
>>> activity. We can see that the UPS server thinks it has sent the test
>>> message to the iOS and the Android variants. with no issues. We get 
>>> alerts
>>> for the iOS pop up but nothing for the Android version.
>>>
>>> Notification    Receivers    Status    Timestamp
>>> {"ipAddress?:?XX.YY.ZZ.216","clientIdentifier":"A...    3 
>>> installations    Succeeded    26 Nov, 10:09:04, 2015
>>> Request IP:    XX.YY.ZZ.216    Details
>>> Message:    test11
>>> Variants:
>>> Android Jambuster    Succeeded    1 installations
>>> Jambuster Development    Succeeded    2 installations
>>>
>>>
>>> 1.
>>>
>>> The main UPS console doesn?t report any errors and it states that 
>>> 3
>>> installations are registered. We?ve sent 657 notifications since 
>>> yesterday
>>> trying to see what the problem is. We though that using the UPS 
>>> console
>>> removed any issues with us creating the test message. Since we can 
>>> see the
>>> iOS devices getting the test message, we are struggling to 
>>> understand why
>>> the Android wouldn?t.
>>> 2.
>>>
>>> We?ve tried with the Android app running in the foreground,
>>> background and not running at all to see if that makes any 
>>> difference and
>>> still nothing comes through.
>>> 3.
>>>
>>> If we look at the log files using roc tail, we can see that the
>>> messages get passed on. No error messages are reported.
>>>
>>> 2015/11/26 05:20:38,528 INFO  [PushNotificationSenderEndpoint] (EJB 
>>> default - 7) Processing send request with &apos;[alert=Test12, 
>>> criteria=[aliases=null, deviceTypes=null, categories=null, 
>>> variants=null], time-to-live=-1]&apos; payload
>>> 2015/11/26 05:20:38,530 INFO  [PushNotificationSenderEndpoint] 
>>> (http-/127.3.204.1:8080-5) Message submitted to PushNetworks for 
>>> further processing
>>> 2015/11/26 05:20:38,533 INFO  [GCMPushNotificationSender] (EJB 
>>> default - 7) Sending payload for [1] devices to GCM
>>> 2015/11/26 05:20:38,590 INFO  [GCMPushNotificationSender] (EJB 
>>> default - 7) Message to GCM has been submitted
>>> 2015/11/26 05:20:38,726 INFO  [APNsPushNotificationSender] (EJB 
>>> default - 7) Message to APNs has been submitted
>>>
>>> Whilst it is impossible for people to debug our code and we don?t 
>>> want
>>> people to, we?re struggling to understand what we could have done 
>>> wrong.
>>> The fact we are getting iOS messages through whilst Android messages 
>>> are
>>> failing (but with no error) is perplexing. We have rebuild the 
>>> Server API
>>> kets in Google, deleted and rebuilt the Android variant but we?ve 
>>> now hit a
>>> brick wall. We have a nagging feeling it is something to do with the 
>>> GCM
>>> Server API key but everything reports OK.
>>>
>>> Any and all suggestions gratefully received.
>>>
>>> Thanks
>>>
>>> Rob
>>>
>>> _______________________________________________
>>> Aerogear-users mailing list
>>> Aerogear-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>
>>>
>>
>>
>> --
>> -- Passos
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users


From scm.blanc at gmail.com  Thu Nov 26 09:45:00 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Thu, 26 Nov 2015 15:45:00 +0100
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <E6446965-1700-4D5C-A91A-994B1745D8BE@robertwillett.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<E6446965-1700-4D5C-A91A-994B1745D8BE@robertwillett.com>
Message-ID: <CAD_dpu2HV=GjBAs02yCZrOPzk+mvYiun4sN702dw_dEG2dKPDg@mail.gmail.com>

On Thu, Nov 26, 2015 at 3:38 PM, Rob Willett <rob.aerogear at robertwillett.com
> wrote:

> Daniel,
>
> Thanks for the reply and the diagram.
>
> We are definitely sending the right project number.
>
> and here?s the same thing in the UPS console. We?ve obscured the Google
> Cloud messaging Key. Thats the one thing we are not certain on. Do you mind
> saying if your GCM Key starts 5xxxxx or AlZa as ours does. The UPS docs are
> little unclear here.
>
I can confirm that my keys starts also with AIza , you're saying that the
placeholder in this screenshot
https://aerogear.org/docs/unifiedpush/aerogear-push-android//img/variant_01.png
is confusing ? I agree, let me fill a ticket for that.


>
>
> Rob
>
>
>
>
> On 26 Nov 2015, at 14:27, Daniel Passos wrote:
>
> It's seems to me some config problem. Are you sure you are using the
>> correct project number in "senderID" instead of project id?
>>
>> http://monosnap.com/file/QmMAO1JQ4aWynfmatYat66vipsYxjr
>>
>> On Thu, Nov 26, 2015 at 8:24 AM, Rob Willett <
>> rob.aerogear at robertwillett.com
>>
>>> wrote:
>>>
>>
>> Hi,
>>>
>>> We?ve got iOS notifications working well and so we thought we?d push our
>>> luck and get Android notifications up and running. We?ve had them working
>>> before with another plugin so it can?t be that difficult?.
>>>
>>> We?ve followed the guide from here
>>>
>>>
>>>
>>> https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troubleshooting
>>>
>>> The Google web interface has changed but its still pretty much the same.
>>>
>>> 1.
>>>
>>> We?ve got and logged the Project Number (which is the Sender Id).
>>> 2.
>>>
>>> We?ve created a new server API key (is this the same as the GCM
>>> Messaging key?)
>>>
>>> This appears to be all thats needed. We have an very old version of our
>>> app sitting in development in the Google Play Store but its never been
>>> released as we focussed on the iOS version. That used to linked to the
>>> GCM
>>> information but we have unlinked that now.
>>>
>>> 1.
>>>
>>> We have created a new variant on the UPS for Android. We create a
>>> name, description and where it asks for the Google Cloud Messaging Key we
>>> enter the Server API key we created in point 2. This is a bit we are
>>> unclear about, is the google Cloud Messaging Key the same as the Server
>>> API
>>> key we generated in Google Play services console? One of the things we
>>> noticed is that the example Google Cloud Messaging Key in the UPS
>>> dialogue
>>> box starts with a different few header bytes e.g. 5a44 whereas all the
>>> Server ApI keys start Alza. We are not experts on cryptography but we
>>> thought that *might* indicate a different type of key. It also might
>>> be nothing at all and Google has simply updated something.
>>> 2.
>>>
>>> We add in the Project number.
>>> 3.
>>>
>>> This creates the Android variant in the UPS dashboard. If we click on
>>> the variant we can see the expanded information showing the Server URL,
>>> the
>>> Variant ID and the Variant Secret.
>>> 4.
>>>
>>> This seems to work much the same as the iOS variant.
>>> 5.
>>>
>>> We then update our Cordova app and update the pushConfig field.
>>>
>>>              var aeroGearPushConfig = {
>>>                  pushServerURL: "
>>> https://push-jambuster.rhcloud.com/ag-push/", // Checked that this
>>> matches the Android variant.
>>>                  ios: {
>>>                      variantID: ?XXXXX-TTTc-OOOO-RRRR-BBBHBHBH?, //
>>> Obscured
>>>                      variantSecret: ?JKJKJ-HHHH-PPOPIO-sdsds-1231232? //
>>> Obscured
>>>                  } ,
>>>                  android: {
>>>                      senderID: ?XXXXXX? , // Changed to protect the
>>> innocent but checked that the senderID is the same as the Google Project Id
>>>                      variantID: ?345345-345345-45345-xxxx-zzzzz? , //
>>> Changed but checked to make sure this is the Android VariantId
>>>                      variantSecret:
>>> "9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to make sure
>>> this is the Android VariantSecret
>>>                  } ,
>>>                  sendMetricInfo: true,
>>>                  alias: UUID // This is a unique string
>>>              };
>>>
>>> We compile and run it on a real device, a Nexus 5. We create a unique
>>> alias to be sent to be sent as the alias. This is the UUID field
>>>
>>> 1.
>>>
>>> When we run the code and inspect the output in Chrome, the aeroGear
>>> Success Handler is called which we hope means success.
>>> 2.
>>>
>>> When we inspect the variant in the UPS dashboard, we can see that the
>>> a device with the right alias is created. The alias matches the alias we
>>> sent.
>>> 3.
>>>
>>> This all looks good. We have three real (i.e. non simulator) test
>>> devices in our UPS dashboard, two iOS devices and one Android device.
>>> 4.
>>>
>>> We click on the Send Push icon in the UPS dashboard to create some
>>> sample notifications. We send a simple test message to all variants. The
>>> two iPhones each get the test message and the Android phone doesn?t.
>>> 5.
>>>
>>> We click on the Dashboard icon in the UPS console, and then recent
>>> activity. We can see that the UPS server thinks it has sent the test
>>> message to the iOS and the Android variants. with no issues. We get
>>> alerts
>>> for the iOS pop up but nothing for the Android version.
>>>
>>> Notification    Receivers    Status    Timestamp
>>> {"ipAddress?:?XX.YY.ZZ.216","clientIdentifier":"A...    3 installations
>>>   Succeeded    26 Nov, 10:09:04, 2015
>>> Request IP:    XX.YY.ZZ.216    Details
>>> Message:    test11
>>> Variants:
>>> Android Jambuster    Succeeded    1 installations
>>> Jambuster Development    Succeeded    2 installations
>>>
>>>
>>> 1.
>>>
>>> The main UPS console doesn?t report any errors and it states that 3
>>> installations are registered. We?ve sent 657 notifications since
>>> yesterday
>>> trying to see what the problem is. We though that using the UPS console
>>> removed any issues with us creating the test message. Since we can see
>>> the
>>> iOS devices getting the test message, we are struggling to understand why
>>> the Android wouldn?t.
>>> 2.
>>>
>>> We?ve tried with the Android app running in the foreground, background
>>> and not running at all to see if that makes any difference and still
>>> nothing comes through.
>>> 3.
>>>
>>>
>>> If we look at the log files using roc tail, we can see that the
>>> messages get passed on. No error messages are reported.
>>>
>>> 2015/11/26 05:20:38,528 INFO  [PushNotificationSenderEndpoint] (EJB
>>> default - 7) Processing send request with &apos;[alert=Test12,
>>> criteria=[aliases=null, deviceTypes=null, categories=null, variants=null],
>>> time-to-live=-1]&apos; payload
>>> 2015/11/26 05:20:38,530 INFO  [PushNotificationSenderEndpoint]
>>> (http-/127.3.204.1:8080-5) Message submitted to PushNetworks for
>>> further processing
>>> 2015/11/26 05:20:38,533 INFO  [GCMPushNotificationSender] (EJB default -
>>> 7) Sending payload for [1] devices to GCM
>>> 2015/11/26 05:20:38,590 INFO  [GCMPushNotificationSender] (EJB default -
>>> 7) Message to GCM has been submitted
>>> 2015/11/26 05:20:38,726 INFO  [APNsPushNotificationSender] (EJB default
>>> - 7) Message to APNs has been submitted
>>>
>>> Whilst it is impossible for people to debug our code and we don?t want
>>> people to, we?re struggling to understand what we could have done wrong.
>>> The fact we are getting iOS messages through whilst Android messages are
>>> failing (but with no error) is perplexing. We have rebuild the Server API
>>> kets in Google, deleted and rebuilt the Android variant but we?ve now
>>> hit a
>>> brick wall. We have a nagging feeling it is something to do with the GCM
>>> Server API key but everything reports OK.
>>>
>>> Any and all suggestions gratefully received.
>>>
>>> Thanks
>>>
>>> Rob
>>>
>>> _______________________________________________
>>> Aerogear-users mailing list
>>> Aerogear-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>
>>>
>>>
>>
>> --
>> -- Passos
>> _______________________________________________
>> Aerogear-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>
> _______________________________________________
> 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-users/attachments/20151126/21d79fe6/attachment-0001.html 

From rob.aerogear at robertwillett.com  Thu Nov 26 10:09:46 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Thu, 26 Nov 2015 15:09:46 +0000
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <CAD_dpu2HV=GjBAs02yCZrOPzk+mvYiun4sN702dw_dEG2dKPDg@mail.gmail.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<E6446965-1700-4D5C-A91A-994B1745D8BE@robertwillett.com>
	<CAD_dpu2HV=GjBAs02yCZrOPzk+mvYiun4sN702dw_dEG2dKPDg@mail.gmail.com>
Message-ID: <4E51BCFB-C2AE-4D75-A19F-61BFA4FC630F@robertwillett.com>

Sebastien,

Thats good to know that your key starts the same as mine. Can I suggest 
that we have a standard name for what this key is?

The docs refer to ?Client ID?, ?Server Key? and ?Google Cloud 
Messaging Key?

?In the Wizard after you create a PushApplication, click the Add 
Variant button and fill out the Android options. You will want to use 
the ***Client ID*** and Project Number from the Google API Console in 
their appropriate fields:?

?On the last screen we are finally get to see the actual value of the 
generated ***Server Key***, which we will use later:?

?Google Cloud Messaging Key? is on the dialogue box that pops up 
when you create the Android Variant.

I think that ?Client ID?, ?Server Key? and ?Google Cloud 
Messaging Key? are actually all the same key, the one created in this 
attachment

Are they all the same k,ey?

Rob

On 26 Nov 2015, at 14:45, Sebastien Blanc wrote:

> On Thu, Nov 26, 2015 at 3:38 PM, Rob Willett 
> <rob.aerogear at robertwillett.com
>> wrote:
>
>> Daniel,
>>
>> Thanks for the reply and the diagram.
>>
>> We are definitely sending the right project number.
>>
>> and here?s the same thing in the UPS console. We?ve obscured the 
>> Google
>> Cloud messaging Key. Thats the one thing we are not certain on. Do 
>> you mind
>> saying if your GCM Key starts 5xxxxx or AlZa as ours does. The UPS 
>> docs are
>> little unclear here.
>>
> I can confirm that my keys starts also with AIza , you're saying that 
> the
> placeholder in this screenshot
> https://aerogear.org/docs/unifiedpush/aerogear-push-android//img/variant_01.png
> is confusing ? I agree, let me fill a ticket for that.
>
>
>>
>>
>> Rob
>>
>>
>>
>>
>> On 26 Nov 2015, at 14:27, Daniel Passos wrote:
>>
>> It's seems to me some config problem. Are you sure you are using the
>>> correct project number in "senderID" instead of project id?
>>>
>>> http://monosnap.com/file/QmMAO1JQ4aWynfmatYat66vipsYxjr
>>>
>>> On Thu, Nov 26, 2015 at 8:24 AM, Rob Willett <
>>> rob.aerogear at robertwillett.com
>>>
>>>> wrote:
>>>>
>>>
>>> Hi,
>>>>
>>>> We?ve got iOS notifications working well and so we thought we?d 
>>>> push our
>>>> luck and get Android notifications up and running. We?ve had them 
>>>> working
>>>> before with another plugin so it can?t be that difficult?.
>>>>
>>>> We?ve followed the guide from here
>>>>
>>>>
>>>>
>>>> https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troubleshooting
>>>>
>>>> The Google web interface has changed but its still pretty much the 
>>>> same.
>>>>
>>>> 1.
>>>>
>>>> We?ve got and logged the Project Number (which is the Sender Id).
>>>> 2.
>>>>
>>>> We?ve created a new server API key (is this the same as the GCM
>>>> Messaging key?)
>>>>
>>>> This appears to be all thats needed. We have an very old version of 
>>>> our
>>>> app sitting in development in the Google Play Store but its never 
>>>> been
>>>> released as we focussed on the iOS version. That used to linked to 
>>>> the
>>>> GCM
>>>> information but we have unlinked that now.
>>>>
>>>> 1.
>>>>
>>>> We have created a new variant on the UPS for Android. We create a
>>>> name, description and where it asks for the Google Cloud Messaging 
>>>> Key we
>>>> enter the Server API key we created in point 2. This is a bit we 
>>>> are
>>>> unclear about, is the google Cloud Messaging Key the same as the 
>>>> Server
>>>> API
>>>> key we generated in Google Play services console? One of the things 
>>>> we
>>>> noticed is that the example Google Cloud Messaging Key in the UPS
>>>> dialogue
>>>> box starts with a different few header bytes e.g. 5a44 whereas all 
>>>> the
>>>> Server ApI keys start Alza. We are not experts on cryptography but 
>>>> we
>>>> thought that *might* indicate a different type of key. It also 
>>>> might
>>>> be nothing at all and Google has simply updated something.
>>>> 2.
>>>>
>>>> We add in the Project number.
>>>> 3.
>>>>
>>>> This creates the Android variant in the UPS dashboard. If we click 
>>>> on
>>>> the variant we can see the expanded information showing the Server 
>>>> URL,
>>>> the
>>>> Variant ID and the Variant Secret.
>>>> 4.
>>>>
>>>> This seems to work much the same as the iOS variant.
>>>> 5.
>>>>
>>>> We then update our Cordova app and update the pushConfig field.
>>>>
>>>>      var aeroGearPushConfig = {
>>>>          pushServerURL: "
>>>> https://push-jambuster.rhcloud.com/ag-push/", // Checked that this
>>>> matches the Android variant.
>>>>          ios: {
>>>>              variantID: ?XXXXX-TTTc-OOOO-RRRR-BBBHBHBH?, //
>>>> Obscured
>>>>              variantSecret: ?JKJKJ-HHHH-PPOPIO-sdsds-1231232? 
>>>> //
>>>> Obscured
>>>>          } ,
>>>>          android: {
>>>>              senderID: ?XXXXXX? , // Changed to protect the
>>>> innocent but checked that the senderID is the same as the Google 
>>>> Project Id
>>>>              variantID: ?345345-345345-45345-xxxx-zzzzz? , //
>>>> Changed but checked to make sure this is the Android VariantId
>>>>              variantSecret:
>>>> "9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to 
>>>> make sure
>>>> this is the Android VariantSecret
>>>>          } ,
>>>>          sendMetricInfo: true,
>>>>          alias: UUID // This is a unique string
>>>>      };
>>>>
>>>> We compile and run it on a real device, a Nexus 5. We create a 
>>>> unique
>>>> alias to be sent to be sent as the alias. This is the UUID field
>>>>
>>>> 1.
>>>>
>>>> When we run the code and inspect the output in Chrome, the aeroGear
>>>> Success Handler is called which we hope means success.
>>>> 2.
>>>>
>>>> When we inspect the variant in the UPS dashboard, we can see that 
>>>> the
>>>> a device with the right alias is created. The alias matches the 
>>>> alias we
>>>> sent.
>>>> 3.
>>>>
>>>> This all looks good. We have three real (i.e. non simulator) test
>>>> devices in our UPS dashboard, two iOS devices and one Android 
>>>> device.
>>>> 4.
>>>>
>>>> We click on the Send Push icon in the UPS dashboard to create some
>>>> sample notifications. We send a simple test message to all 
>>>> variants. The
>>>> two iPhones each get the test message and the Android phone 
>>>> doesn?t.
>>>> 5.
>>>>
>>>> We click on the Dashboard icon in the UPS console, and then recent
>>>> activity. We can see that the UPS server thinks it has sent the 
>>>> test
>>>> message to the iOS and the Android variants. with no issues. We get
>>>> alerts
>>>> for the iOS pop up but nothing for the Android version.
>>>>
>>>> Notification    Receivers    Status    Timestamp
>>>> {"ipAddress?:?XX.YY.ZZ.216","clientIdentifier":"A...    3 
>>>> installations
>>>> Succeeded    26 Nov, 10:09:04, 2015
>>>> Request IP:    XX.YY.ZZ.216    Details
>>>> Message:    test11
>>>> Variants:
>>>> Android Jambuster    Succeeded    1 installations
>>>> Jambuster Development    Succeeded    2 installations
>>>>
>>>>
>>>> 1.
>>>>
>>>> The main UPS console doesn?t report any errors and it states that 
>>>> 3
>>>> installations are registered. We?ve sent 657 notifications since
>>>> yesterday
>>>> trying to see what the problem is. We though that using the UPS 
>>>> console
>>>> removed any issues with us creating the test message. Since we can 
>>>> see
>>>> the
>>>> iOS devices getting the test message, we are struggling to 
>>>> understand why
>>>> the Android wouldn?t.
>>>> 2.
>>>>
>>>> We?ve tried with the Android app running in the foreground, 
>>>> background
>>>> and not running at all to see if that makes any difference and 
>>>> still
>>>> nothing comes through.
>>>> 3.
>>>>
>>>>
>>>> If we look at the log files using roc tail, we can see that the
>>>> messages get passed on. No error messages are reported.
>>>>
>>>> 2015/11/26 05:20:38,528 INFO  [PushNotificationSenderEndpoint] (EJB
>>>> default - 7) Processing send request with &apos;[alert=Test12,
>>>> criteria=[aliases=null, deviceTypes=null, categories=null, 
>>>> variants=null],
>>>> time-to-live=-1]&apos; payload
>>>> 2015/11/26 05:20:38,530 INFO  [PushNotificationSenderEndpoint]
>>>> (http-/127.3.204.1:8080-5) Message submitted to PushNetworks for
>>>> further processing
>>>> 2015/11/26 05:20:38,533 INFO  [GCMPushNotificationSender] (EJB 
>>>> default -
>>>> 7) Sending payload for [1] devices to GCM
>>>> 2015/11/26 05:20:38,590 INFO  [GCMPushNotificationSender] (EJB 
>>>> default -
>>>> 7) Message to GCM has been submitted
>>>> 2015/11/26 05:20:38,726 INFO  [APNsPushNotificationSender] (EJB 
>>>> default
>>>> - 7) Message to APNs has been submitted
>>>>
>>>> Whilst it is impossible for people to debug our code and we don?t 
>>>> want
>>>> people to, we?re struggling to understand what we could have done 
>>>> wrong.
>>>> The fact we are getting iOS messages through whilst Android 
>>>> messages are
>>>> failing (but with no error) is perplexing. We have rebuild the 
>>>> Server API
>>>> kets in Google, deleted and rebuilt the Android variant but we?ve 
>>>> now
>>>> hit a
>>>> brick wall. We have a nagging feeling it is something to do with 
>>>> the GCM
>>>> Server API key but everything reports OK.
>>>>
>>>> Any and all suggestions gratefully received.
>>>>
>>>> Thanks
>>>>
>>>> Rob
>>>>
>>>> _______________________________________________
>>>> Aerogear-users mailing list
>>>> Aerogear-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>>
>>>>
>>>
>>> --
>>> -- Passos
>>> _______________________________________________
>>> Aerogear-users mailing list
>>> Aerogear-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
> _______________________________________________
> 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-users/attachments/20151126/d2cd5700/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Google API Screen.jpg
Type: image/jpeg
Size: 33966 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-users/attachments/20151126/d2cd5700/attachment-0001.jpg 

From scm.blanc at gmail.com  Thu Nov 26 10:16:33 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Thu, 26 Nov 2015 16:16:33 +0100
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <4E51BCFB-C2AE-4D75-A19F-61BFA4FC630F@robertwillett.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<E6446965-1700-4D5C-A91A-994B1745D8BE@robertwillett.com>
	<CAD_dpu2HV=GjBAs02yCZrOPzk+mvYiun4sN702dw_dEG2dKPDg@mail.gmail.com>
	<4E51BCFB-C2AE-4D75-A19F-61BFA4FC630F@robertwillett.com>
Message-ID: <CAD_dpu3AdR5M1bDcoB9b7RN48ur_+hXnAY-HEQrMB+_5xpUmJA@mail.gmail.com>

On Thu, Nov 26, 2015 at 4:09 PM, Rob Willett <rob.aerogear at robertwillett.com
> wrote:

> Sebastien,
>
> Thats good to know that your key starts the same as mine. Can I suggest
> that we have a standard name for what this key is?
>
> The docs refer to ?Client ID?, ?Server Key? and ?Google Cloud Messaging
> Key?
>
> ?In the Wizard after you create a PushApplication, click the Add Variant
> button and fill out the Android options. You will want to use the *Client
> ID* and Project Number from the Google API Console in their appropriate
> fields:?
>
> ?On the last screen we are finally get to see the actual value of the
> generated *Server Key*, which we will use later:?
>
> ?Google Cloud Messaging Key? is on the dialogue box that pops up when you
> create the Android Variant.
>
> I think that ?Client ID?, ?Server Key? and ?Google Cloud Messaging Key?
> are actually all the same key, the one created in this attachment
>
> Are they all the same k,ey?
>
Yes there are and you are right it's really confusing, I add a comment to
the existing ticket about the  doc polishing
Thx again.

> Rob
>
> On 26 Nov 2015, at 14:45, Sebastien Blanc wrote:
>
> On Thu, Nov 26, 2015 at 3:38 PM, Rob Willett <
> rob.aerogear at robertwillett.com
>
> wrote:
>
> Daniel,
>
> Thanks for the reply and the diagram.
>
> We are definitely sending the right project number.
>
> and here?s the same thing in the UPS console. We?ve obscured the Google
> Cloud messaging Key. Thats the one thing we are not certain on. Do you mind
> saying if your GCM Key starts 5xxxxx or AlZa as ours does. The UPS docs are
> little unclear here.
>
> I can confirm that my keys starts also with AIza , you're saying that the
> placeholder in this screenshot
>
> https://aerogear.org/docs/unifiedpush/aerogear-push-android//img/variant_01.png
> is confusing ? I agree, let me fill a ticket for that.
>
> Rob
>
> On 26 Nov 2015, at 14:27, Daniel Passos wrote:
>
> It's seems to me some config problem. Are you sure you are using the
>
> correct project number in "senderID" instead of project id?
>
> http://monosnap.com/file/QmMAO1JQ4aWynfmatYat66vipsYxjr
>
> On Thu, Nov 26, 2015 at 8:24 AM, Rob Willett <
> rob.aerogear at robertwillett.com
>
> wrote:
>
> Hi,
>
> We?ve got iOS notifications working well and so we thought we?d push our
> luck and get Android notifications up and running. We?ve had them working
> before with another plugin so it can?t be that difficult?.
>
> We?ve followed the guide from here
>
>
> https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troubleshooting
>
> The Google web interface has changed but its still pretty much the same.
>
> 1.
>
> We?ve got and logged the Project Number (which is the Sender Id).
> 2.
>
> We?ve created a new server API key (is this the same as the GCM
> Messaging key?)
>
> This appears to be all thats needed. We have an very old version of our
> app sitting in development in the Google Play Store but its never been
> released as we focussed on the iOS version. That used to linked to the
> GCM
> information but we have unlinked that now.
>
> 1.
>
> We have created a new variant on the UPS for Android. We create a
> name, description and where it asks for the Google Cloud Messaging Key we
> enter the Server API key we created in point 2. This is a bit we are
> unclear about, is the google Cloud Messaging Key the same as the Server
> API
> key we generated in Google Play services console? One of the things we
> noticed is that the example Google Cloud Messaging Key in the UPS
> dialogue
> box starts with a different few header bytes e.g. 5a44 whereas all the
> Server ApI keys start Alza. We are not experts on cryptography but we
> thought that *might* indicate a different type of key. It also might
>
> be nothing at all and Google has simply updated something.
> 2.
>
> We add in the Project number.
> 3.
>
> This creates the Android variant in the UPS dashboard. If we click on
> the variant we can see the expanded information showing the Server URL,
> the
> Variant ID and the Variant Secret.
> 4.
>
> This seems to work much the same as the iOS variant.
> 5.
>
> We then update our Cordova app and update the pushConfig field.
>
>  var aeroGearPushConfig = {
>      pushServerURL: "
>
> https://push-jambuster.rhcloud.com/ag-push/", // Checked that this
> matches the Android variant.
> ios: {
> variantID: ?XXXXX-TTTc-OOOO-RRRR-BBBHBHBH?, //
> Obscured
> variantSecret: ?JKJKJ-HHHH-PPOPIO-sdsds-1231232? //
> Obscured
> } ,
> android: {
> senderID: ?XXXXXX? , // Changed to protect the
> innocent but checked that the senderID is the same as the Google Project Id
> variantID: ?345345-345345-45345-xxxx-zzzzz? , //
> Changed but checked to make sure this is the Android VariantId
> variantSecret:
> "9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to make sure
> this is the Android VariantSecret
> } ,
> sendMetricInfo: true,
> alias: UUID // This is a unique string
> };
>
> We compile and run it on a real device, a Nexus 5. We create a unique
> alias to be sent to be sent as the alias. This is the UUID field
>
> 1.
>
> When we run the code and inspect the output in Chrome, the aeroGear
> Success Handler is called which we hope means success.
> 2.
>
> When we inspect the variant in the UPS dashboard, we can see that the
> a device with the right alias is created. The alias matches the alias we
> sent.
> 3.
>
> This all looks good. We have three real (i.e. non simulator) test
> devices in our UPS dashboard, two iOS devices and one Android device.
> 4.
>
> We click on the Send Push icon in the UPS dashboard to create some
> sample notifications. We send a simple test message to all variants. The
> two iPhones each get the test message and the Android phone doesn?t.
> 5.
>
> We click on the Dashboard icon in the UPS console, and then recent
> activity. We can see that the UPS server thinks it has sent the test
> message to the iOS and the Android variants. with no issues. We get
> alerts
> for the iOS pop up but nothing for the Android version.
>
> Notification Receivers Status Timestamp
> {"ipAddress?:?XX.YY.ZZ.216","clientIdentifier":"A... 3 installations
> Succeeded 26 Nov, 10:09:04, 2015
> Request IP: XX.YY.ZZ.216 Details
> Message: test11
> Variants:
> Android Jambuster Succeeded 1 installations
> Jambuster Development Succeeded 2 installations
>
> 1.
>
> The main UPS console doesn?t report any errors and it states that 3
> installations are registered. We?ve sent 657 notifications since
> yesterday
> trying to see what the problem is. We though that using the UPS console
> removed any issues with us creating the test message. Since we can see
> the
> iOS devices getting the test message, we are struggling to understand why
> the Android wouldn?t.
> 2.
>
> We?ve tried with the Android app running in the foreground, background
> and not running at all to see if that makes any difference and still
> nothing comes through.
> 3.
>
> If we look at the log files using roc tail, we can see that the
> messages get passed on. No error messages are reported.
>
> 2015/11/26 05:20:38,528 INFO PushNotificationSenderEndpoint
> <http://EJB%0Adefault%20-%207> Processing send request with
> '[alert=Test12,
> criteria=[aliases=null, deviceTypes=null, categories=null, variants=null],
> time-to-live=-1]' payload
> 2015/11/26 05:20:38,530 INFO PushNotificationSenderEndpoint
> <http://http-/127.3.204.1:8080-5> Message submitted to PushNetworks for
> further processing
> 2015/11/26 05:20:38,533 INFO GCMPushNotificationSender
> <http://EJB%20default%20-%0A7> Sending payload for [1] devices to GCM
> 2015/11/26 05:20:38,590 INFO GCMPushNotificationSender
> <http://EJB%20default%20-%0A7> Message to GCM has been submitted
> 2015/11/26 05:20:38,726 INFO APNsPushNotificationSender
> <http://EJB%20default%0A-%207> Message to APNs has been submitted
>
> Whilst it is impossible for people to debug our code and we don?t want
> people to, we?re struggling to understand what we could have done wrong.
> The fact we are getting iOS messages through whilst Android messages are
> failing (but with no error) is perplexing. We have rebuild the Server API
> kets in Google, deleted and rebuilt the Android variant but we?ve now
> hit a
> brick wall. We have a nagging feeling it is something to do with the GCM
> Server API key but everything reports OK.
>
> Any and all suggestions gratefully received.
>
> Thanks
>
> Rob
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> --
> -- Passos
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
> _______________________________________________
> 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-users/attachments/20151126/70c42761/attachment.html 

From rob.aerogear at robertwillett.com  Thu Nov 26 10:36:55 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Thu, 26 Nov 2015 15:36:55 +0000
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
Message-ID: <BA8854A1-072A-4B16-B524-3B7CEAB283F5@robertwillett.com>

Sebastien,

We?ve checked and Google Cloud Messaging is enabled

We?ve created a whole new Google project and started again. We?ve 
created the Google GCM Server API key again, we?ve deleted the old 
variant and created a new one with the new server API key and the new 
Google project number. I?m going to start publishing the keys and the 
secrets as it makes it difficult to follow exactly what has been done 
and where. Once we have it working, I?ll remove the old Google project 
and start again.

We?ve updated our Cordova project with the new variant information and 
restarted up our Cordova app. We can see the Alias we created in our 
Android version in the Android Push variant along with a Device Token. 
The alias matches our Android alias that we uploaded.

We fire up android and look at the logcat output. Rather scary?

We send a new Push from the UPS console with the app in foreground, 
background and not fired up.

```
E/WifiStateMachine(  740): WifiStateMachine CMD_START_SCAN source -2 
txSuccessRate=2.06 rxSuccessRate=2.05 targetRoamBSSID=30:85:a9:6d:dc:fc 
RSSI=-78
E/WifiStateMachine(  740): WifiStateMachine starting scan for 
?XXXX?WPA_PSK with 5240
I/wpa_supplicant(  939): wlan0: CTRL-EVENT-SCAN-STARTED
I/art     (  740): Explicit concurrent mark sweep GC freed 159875(7MB) 
AllocSpace objects, 8(128KB) LOS objects, 29% free, 37MB/53MB, paused 
1.177ms total 96.881ms
I/EventLogService( 1730): Opted in for usage reporting
I/EventLogService( 1730): Aggregate from 1448549400100 (log), 
1448549400100 (data)
I/SyncAdapterService(24506): Ignoring sync request for inactive user
I/ServiceDumpSys( 1730): dumping service [account]
E/WifiStateMachine(  740): WifiStateMachine CMD_START_SCAN source -2 
txSuccessRate=0.76 rxSuccessRate=2.76 targetRoamBSSID=30:85:a9:6d:dc:fc 
RSSI=-77
E/WifiStateMachine(  740): WifiStateMachine starting scan for 
?XXXXX?WPA_PSK with 5240
I/wpa_supplicant(  939): wlan0: CTRL-EVENT-SCAN-STARTED
E/WifiStateMachine(  740): WifiStateMachine CMD_START_SCAN source -2 
txSuccessRate=1.65 rxSuccessRate=2.54 targetRoamBSSID=30:85:a9:6d:dc:fc 
RSSI=-78
E/WifiStateMachine(  740): WifiStateMachine starting scan for 
?XXXXX?WPA_PSK with 5240
I/wpa_supplicant(  939): wlan0: CTRL-EVENT-SCAN-STARTED
```

Nothing obvious appears in the logcat output.

We have looked in the log of the Push server and can see the message 
being sent to GCM

```
2015/11/26 10:22:00,265 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n] 
(http-/127.3.204.1:8080-3) RESTEASY000235: Field clientConnection of 
subresource org.keycloak.services.resources.TokenService will not be 
injected according to spec
2015/11/26 10:22:12,244 INFO  [PushNotificationSenderEndpoint] 
(http-/127.3.204.1:8080-3) Message submitted to PushNetworks for further 
processing
2015/11/26 10:22:12,244 INFO  [PushNotificationSenderEndpoint] (EJB 
default - 6) Processing send request with &apos;[alert=Test 16, 
criteria=[aliases=null, deviceTypes=null, categories=null, 
variants=null], time-to-live=-1]&apos; payload
2015/11/26 10:22:12,364 INFO  [APNsPushNotificationSender] (EJB default 
- 6) Message to APNs has been submitted
2015/11/26 10:22:12,487 INFO  [GCMPushNotificationSender] (EJB default - 
6) Sending payload for [1] devices to GCM
2015/11/26 10:22:12,546 INFO  [GCMPushNotificationSender] (EJB default - 
6) Message to GCM has been submitted
2015/11/26 10:22:15,267 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n] 
(http-/127.3.204.1:8080-3) RESTEASY000235: Field providers of 
subresource org.keycloak.services.resources.TokenService will not be 
injected according to spec
```

The Aerogear Console also reports that the test pushes have gone AND 
that they succeeded.

I can?t believe that we have missed a simple configuration issue on 
the UnifiedPush server.

We?ll try and bypass the UPS console and write direct to GCM now 
through curl or something. Do you know if the device token in the UPS 
console is the Android token to use?

Thanks

Rob

On 26 Nov 2015, at 14:33, Sebastien Blanc wrote:

> Hi Rob,
>
> Maybe obvious but just to be sure :  have you enabled "Google Cloud
> Messaging for Android" API ?
>
> You also mention that you are using an old project, I have seen before
> issues with my old projects, could you create a new google project to 
> see
> if that helps ?
>
> Last point : have you checked in the Android logs (logcat) that the 
> message
> really dies not arrive ?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151126/797ac43f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2015-11-26 at 15.14.27.png
Type: image/png
Size: 22359 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-users/attachments/20151126/797ac43f/attachment-0001.png 

From scm.blanc at gmail.com  Thu Nov 26 10:49:08 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Thu, 26 Nov 2015 16:49:08 +0100
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <BA8854A1-072A-4B16-B524-3B7CEAB283F5@robertwillett.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
	<BA8854A1-072A-4B16-B524-3B7CEAB283F5@robertwillett.com>
Message-ID: <CAD_dpu1Efe_fdj24sNo-rTAJS4Om7L-knmt3ZVY7WB4VTphSHw@mail.gmail.com>

On Thu, Nov 26, 2015 at 4:36 PM, Rob Willett <rob.aerogear at robertwillett.com
> wrote:

> Sebastien,
>
> We?ve checked and Google Cloud Messaging is enabled
>
> We?ve created a whole new Google project and started again. We?ve created
> the Google GCM Server API key again, we?ve deleted the old variant and
> created a new one with the new server API key and the new Google project
> number. I?m going to start publishing the keys and the secrets as it makes
> it difficult to follow exactly what has been done and where. Once we have
> it working, I?ll remove the old Google project and start again.
>
> We?ve updated our Cordova project with the new variant information and
> restarted up our Cordova app. We can see the Alias we created in our
> Android version in the Android Push variant along with a Device Token. The
> alias matches our Android alias that we uploaded.
>
> We fire up android and look at the logcat output. Rather scary?
>
> We send a new Push from the UPS console with the app in foreground,
> background and not fired up.
>
> E/WifiStateMachine(  740): WifiStateMachine CMD_START_SCAN source -2 txSuccessRate=2.06 rxSuccessRate=2.05 targetRoamBSSID=30:85:a9:6d:dc:fc RSSI=-78
> E/WifiStateMachine(  740): WifiStateMachine starting scan for ?XXXX?WPA_PSK with 5240
> I/wpa_supplicant(  939): wlan0: CTRL-EVENT-SCAN-STARTED
> I/art     (  740): Explicit concurrent mark sweep GC freed 159875(7MB) AllocSpace objects, 8(128KB) LOS objects, 29% free, 37MB/53MB, paused 1.177ms total 96.881ms
> I/EventLogService( 1730): Opted in for usage reporting
> I/EventLogService( 1730): Aggregate from 1448549400100 (log), 1448549400100 (data)
> I/SyncAdapterService(24506): Ignoring sync request for inactive user
> I/ServiceDumpSys( 1730): dumping service [account]
> E/WifiStateMachine(  740): WifiStateMachine CMD_START_SCAN source -2 txSuccessRate=0.76 rxSuccessRate=2.76 targetRoamBSSID=30:85:a9:6d:dc:fc RSSI=-77
> E/WifiStateMachine(  740): WifiStateMachine starting scan for ?XXXXX?WPA_PSK with 5240
> I/wpa_supplicant(  939): wlan0: CTRL-EVENT-SCAN-STARTED
> E/WifiStateMachine(  740): WifiStateMachine CMD_START_SCAN source -2 txSuccessRate=1.65 rxSuccessRate=2.54 targetRoamBSSID=30:85:a9:6d:dc:fc RSSI=-78
> E/WifiStateMachine(  740): WifiStateMachine starting scan for ?XXXXX?WPA_PSK with 5240
> I/wpa_supplicant(  939): wlan0: CTRL-EVENT-SCAN-STARTED
>
> Nothing obvious appears in the logcat output.
>
> We have looked in the log of the Push server and can see the message being
> sent to GCM
>
> 2015/11/26 10:22:00,265 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n] (http-/127.3.204.1:8080-3) RESTEASY000235: Field clientConnection of subresource org.keycloak.services.resources.TokenService will not be injected according to spec
> 2015/11/26 10:22:12,244 INFO  [PushNotificationSenderEndpoint] (http-/127.3.204.1:8080-3) Message submitted to PushNetworks for further processing
> 2015/11/26 10:22:12,244 INFO  [PushNotificationSenderEndpoint] (EJB default - 6) Processing send request with &apos;[alert=Test 16, criteria=[aliases=null, deviceTypes=null, categories=null, variants=null], time-to-live=-1]&apos; payload
> 2015/11/26 10:22:12,364 INFO  [APNsPushNotificationSender] (EJB default - 6) Message to APNs has been submitted
> 2015/11/26 10:22:12,487 INFO  [GCMPushNotificationSender] (EJB default - 6) Sending payload for [1] devices to GCM
> 2015/11/26 10:22:12,546 INFO  [GCMPushNotificationSender] (EJB default - 6) Message to GCM has been submitted
> 2015/11/26 10:22:15,267 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n] (http-/127.3.204.1:8080-3) RESTEASY000235: Field providers of subresource org.keycloak.services.resources.TokenService will not be injected according to spec
>
> The Aerogear Console also reports that the test pushes have gone AND that
> they succeeded.
>
> I can?t believe that we have missed a simple configuration issue on the
> UnifiedPush server.
>
Yes, strange, looks like you are doing everything the correct way

> We?ll try and bypass the UPS console and write direct to GCM now through
> curl or something. Do you know if the device token in the UPS console is
> the Android token to use?
>
That is good test indeed and yes the token in UPS is the one you can use
for your GCM test.

> Thanks
>
> Rob
>
> On 26 Nov 2015, at 14:33, Sebastien Blanc wrote:
>
> Hi Rob,
>
> Maybe obvious but just to be sure : have you enabled "Google Cloud
> Messaging for Android" API ?
>
> You also mention that you are using an old project, I have seen before
> issues with my old projects, could you create a new google project to see
> if that helps ?
>
> Last point : have you checked in the Android logs (logcat) that the message
> really dies not arrive ?
>
>
> _______________________________________________
> 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-users/attachments/20151126/fa9204c3/attachment.html 

From rob.aerogear at robertwillett.com  Thu Nov 26 11:35:36 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Thu, 26 Nov 2015 16:35:36 +0000
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <CAD_dpu1Efe_fdj24sNo-rTAJS4Om7L-knmt3ZVY7WB4VTphSHw@mail.gmail.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
	<BA8854A1-072A-4B16-B524-3B7CEAB283F5@robertwillett.com>
	<CAD_dpu1Efe_fdj24sNo-rTAJS4Om7L-knmt3ZVY7WB4VTphSHw@mail.gmail.com>
Message-ID: <D6F9E760-E031-4A7A-B277-B10DD17BB3E1@robertwillett.com>

Sebastien,

Well we have created and deleted variants and various Google Projects 
all with the result. No notification but no errors.

We have validated the server API key using another curl script

We have managed to write a curl script that almost works but not quite 
:) We get a MismatchSenderId error.

Grepping for this on the intertubes shows a lot of Stackoverflow 
nonsense and some stuff from Google.

What we are now wondering if the device token that we are using, that 
reported by the AeroGear UPS console is actually out of date.

When we delete the variant we create a new variant and register with 
that. The device token created and reported by the UPS console is the 
same as the old variant. We are wondering if this is incorrect and it 
should be a new device token. We?re trying to delete it but you 
can?t seem to delete it from the console and trying to delete it from 
our app calls the Javascript error function.

We?ll keep trying, but our other Android phone packed up yesterday and 
we only one left. We?re pulling out an old Samsung S3 on the off 
chance it might work :)

Any thoughts on invalid device tokens?

Rob

>> I can?t believe that we have missed a simple configuration issue on 
>> the
>> UnifiedPush server.
>>
> Yes, strange, looks like you are doing everything the correct way
>
>> We?ll try and bypass the UPS console and write direct to GCM now 
>> through
>> curl or something. Do you know if the device token in the UPS console 
>> is
>> the Android token to use?
>>
> That is good test indeed and yes the token in UPS is the one you can 
> use
> for your GCM test.
>
>> Thanks


From rob.aerogear at robertwillett.com  Thu Nov 26 11:56:02 2015
From: rob.aerogear at robertwillett.com (Rob Willett)
Date: Thu, 26 Nov 2015 16:56:02 +0000
Subject: [Aerogear-users] Trouble sending Android Push Notifications
 [Solved]
In-Reply-To: <D6F9E760-E031-4A7A-B277-B10DD17BB3E1@robertwillett.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
	<BA8854A1-072A-4B16-B524-3B7CEAB283F5@robertwillett.com>
	<CAD_dpu1Efe_fdj24sNo-rTAJS4Om7L-knmt3ZVY7WB4VTphSHw@mail.gmail.com>
	<D6F9E760-E031-4A7A-B277-B10DD17BB3E1@robertwillett.com>
Message-ID: <7909D286-91DD-4612-BF23-7D703725519C@robertwillett.com>

Got the problem.

The device token that was being reported by the UPS Push Console was 
invalid or out of date.

We wrote a quick JavaScript script to register the device and then 
unregister it.

We then forced our app to register again. The device token was changed 
in the UPS console variant. We tried to do a Send Push from the console 
and it came
through fine.

We now can see notifications :)

Of course its almost the last thing we tried?

Now the issue is should the UPS server have got a new device token if 
the variant was deleted AND the GCM project was deleted? We are not 
clear when the device token is renewed but either

1. The UPS server should do this automatically when variants are deleted 
or some other way of detecting that things have changed.

OR

2. Should the app do it. In which case when should push.unregister() be 
called. Should we unregister and register every time the app starts up 
to make sure the device token is valid. Seems excessive which is why my 
first thought is that this should be server side not client side.

I don?t know what the answer is, but stale Android device tokens have 
been an issue for us. The fact they survive multiple different Google 
Projects AND multiple different UPS variants makes me think this is an 
issue.

Anybody care to comment?

Rob (who is now going got a coffee as he?s earn it)

On 26 Nov 2015, at 16:35, Rob Willett wrote:

> Sebastien,
>
> Well we have created and deleted variants and various Google Projects
> all with the result. No notification but no errors.
>
> We have validated the server API key using another curl script
>
> We have managed to write a curl script that almost works but not quite
> :) We get a MismatchSenderId error.
>
> Grepping for this on the intertubes shows a lot of Stackoverflow
> nonsense and some stuff from Google.
>
> What we are now wondering if the device token that we are using, that
> reported by the AeroGear UPS console is actually out of date.
>
> When we delete the variant we create a new variant and register with
> that. The device token created and reported by the UPS console is the
> same as the old variant. We are wondering if this is incorrect and it
> should be a new device token. We?re trying to delete it but you
> can?t seem to delete it from the console and trying to delete it 
> from
> our app calls the Javascript error function.
>
> We?ll keep trying, but our other Android phone packed up yesterday 
> and
> we only one left. We?re pulling out an old Samsung S3 on the off
> chance it might work :)
>
> Any thoughts on invalid device tokens?
>
> Rob
>
>>> I can?t believe that we have missed a simple configuration issue 
>>> on
>>> the
>>> UnifiedPush server.
>>>
>> Yes, strange, looks like you are doing everything the correct way
>>
>>> We?ll try and bypass the UPS console and write direct to GCM now
>>> through
>>> curl or something. Do you know if the device token in the UPS 
>>> console
>>> is
>>> the Android token to use?
>>>
>> That is good test indeed and yes the token in UPS is the one you can
>> use
>> for your GCM test.
>>
>>> Thanks
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users

From scm.blanc at gmail.com  Thu Nov 26 11:57:16 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Thu, 26 Nov 2015 17:57:16 +0100
Subject: [Aerogear-users] Trouble sending Android Push Notifications
In-Reply-To: <D6F9E760-E031-4A7A-B277-B10DD17BB3E1@robertwillett.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
	<BA8854A1-072A-4B16-B524-3B7CEAB283F5@robertwillett.com>
	<CAD_dpu1Efe_fdj24sNo-rTAJS4Om7L-knmt3ZVY7WB4VTphSHw@mail.gmail.com>
	<D6F9E760-E031-4A7A-B277-B10DD17BB3E1@robertwillett.com>
Message-ID: <CAD_dpu2ZJPovPxRuU6Xgp-h4bP1-5oSna8Q7XgRhMLBO9Dor_g@mail.gmail.com>

On Thu, Nov 26, 2015 at 5:35 PM, Rob Willett <rob.aerogear at robertwillett.com
> wrote:

> Sebastien,
>
> Well we have created and deleted variants and various Google Projects
> all with the result. No notification but no errors.
>
> We have validated the server API key using another curl script
>
> We have managed to write a curl script that almost works but not quite
> :) We get a MismatchSenderId error.
>
> Grepping for this on the intertubes shows a lot of Stackoverflow
> nonsense and some stuff from Google.
>
> What we are now wondering if the device token that we are using, that
> reported by the AeroGear UPS console is actually out of date.
>
> When we delete the variant we create a new variant and register with
> that. The device token created and reported by the UPS console is the
> same as the old variant. We are wondering if this is incorrect and it
> should be a new device token.


The device token is not generated by UPS but by the GCM server who pass it
to the device and the device pass it to UPS when it registers. So even with
a new variant, the device will still returns its allocated device token,
I'm not expert in gcm tokens, I hope Daniel will be able to help more on
this. Maybe uninstalling and wiping all the data of the app will force gcm
to deliver a new and "fresh" token ?

We?re trying to delete it but you
> can?t seem to delete it from the console and trying to delete it from
> our app calls the Javascript error function.
>
> We?ll keep trying, but our other Android phone packed up yesterday and
> we only one left. We?re pulling out an old Samsung S3 on the off
> chance it might work :)
>
> Any thoughts on invalid device tokens?
>
We have a crone job running on UPS that cleans up the invalid tokens.


>
> Rob
>
> >> I can?t believe that we have missed a simple configuration issue on
> >> the
> >> UnifiedPush server.
> >>
> > Yes, strange, looks like you are doing everything the correct way
> >
> >> We?ll try and bypass the UPS console and write direct to GCM now
> >> through
> >> curl or something. Do you know if the device token in the UPS console
> >> is
> >> the Android token to use?
> >>
> > That is good test indeed and yes the token in UPS is the one you can
> > use
> > for your GCM test.
> >
> >> Thanks
>
> _______________________________________________
> 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-users/attachments/20151126/83590718/attachment-0001.html 

From scm.blanc at gmail.com  Thu Nov 26 12:01:00 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Thu, 26 Nov 2015 18:01:00 +0100
Subject: [Aerogear-users] Trouble sending Android Push Notifications
	[Solved]
In-Reply-To: <7909D286-91DD-4612-BF23-7D703725519C@robertwillett.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
	<BA8854A1-072A-4B16-B524-3B7CEAB283F5@robertwillett.com>
	<CAD_dpu1Efe_fdj24sNo-rTAJS4Om7L-knmt3ZVY7WB4VTphSHw@mail.gmail.com>
	<D6F9E760-E031-4A7A-B277-B10DD17BB3E1@robertwillett.com>
	<7909D286-91DD-4612-BF23-7D703725519C@robertwillett.com>
Message-ID: <CAD_dpu2pzWguAcJhNPFHJ75vhNmQ496H4BrtDeEiyoMp7i60Pg@mail.gmail.com>

Great to hear ! And looks like my previous answer was sent while you were
sending this answer :)

As said in my previous answer, we have some running jobs that cleans up
invalid tokens but seeing your issues we need to make that more robust, at
least on our side because maybe things are getting wrong on Google's side
as well.



On Thu, Nov 26, 2015 at 5:56 PM, Rob Willett <rob.aerogear at robertwillett.com
> wrote:

> Got the problem.
>
> The device token that was being reported by the UPS Push Console was
> invalid or out of date.
>
> We wrote a quick JavaScript script to register the device and then
> unregister it.
>
> We then forced our app to register again. The device token was changed
> in the UPS console variant. We tried to do a Send Push from the console
> and it came
> through fine.
>
> We now can see notifications :)
>
> Of course its almost the last thing we tried?
>
> Now the issue is should the UPS server have got a new device token if
> the variant was deleted AND the GCM project was deleted? We are not
> clear when the device token is renewed but either
>
> 1. The UPS server should do this automatically when variants are deleted
> or some other way of detecting that things have changed.
>
> OR
>
> 2. Should the app do it. In which case when should push.unregister() be
> called. Should we unregister and register every time the app starts up
> to make sure the device token is valid. Seems excessive which is why my
> first thought is that this should be server side not client side.
>
> I don?t know what the answer is, but stale Android device tokens have
> been an issue for us. The fact they survive multiple different Google
> Projects AND multiple different UPS variants makes me think this is an
> issue.
>
> Anybody care to comment?
>
> Rob (who is now going got a coffee as he?s earn it)
>
> On 26 Nov 2015, at 16:35, Rob Willett wrote:
>
> > Sebastien,
> >
> > Well we have created and deleted variants and various Google Projects
> > all with the result. No notification but no errors.
> >
> > We have validated the server API key using another curl script
> >
> > We have managed to write a curl script that almost works but not quite
> > :) We get a MismatchSenderId error.
> >
> > Grepping for this on the intertubes shows a lot of Stackoverflow
> > nonsense and some stuff from Google.
> >
> > What we are now wondering if the device token that we are using, that
> > reported by the AeroGear UPS console is actually out of date.
> >
> > When we delete the variant we create a new variant and register with
> > that. The device token created and reported by the UPS console is the
> > same as the old variant. We are wondering if this is incorrect and it
> > should be a new device token. We?re trying to delete it but you
> > can?t seem to delete it from the console and trying to delete it
> > from
> > our app calls the Javascript error function.
> >
> > We?ll keep trying, but our other Android phone packed up yesterday
> > and
> > we only one left. We?re pulling out an old Samsung S3 on the off
> > chance it might work :)
> >
> > Any thoughts on invalid device tokens?
> >
> > Rob
> >
> >>> I can?t believe that we have missed a simple configuration issue
> >>> on
> >>> the
> >>> UnifiedPush server.
> >>>
> >> Yes, strange, looks like you are doing everything the correct way
> >>
> >>> We?ll try and bypass the UPS console and write direct to GCM now
> >>> through
> >>> curl or something. Do you know if the device token in the UPS
> >>> console
> >>> is
> >>> the Android token to use?
> >>>
> >> That is good test indeed and yes the token in UPS is the one you can
> >> use
> >> for your GCM test.
> >>
> >>> Thanks
> >
> > _______________________________________________
> > Aerogear-users mailing list
> > Aerogear-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-users
> _______________________________________________
> 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-users/attachments/20151126/d86e3068/attachment.html 

From alexandre.balleste at udl.cat  Fri Nov 27 03:56:23 2015
From: alexandre.balleste at udl.cat (=?UTF-8?B?QWxleCBCYWxsZXN0w6k=?=)
Date: Fri, 27 Nov 2015 09:56:23 +0100
Subject: [Aerogear-users] Push registration with cordova plugin
Message-ID: <56581AB7.8020808@udl.cat>

Hi, I'm a bit disconcerted about a behaviour of push cordova plugin.

What I'm doing is to use the "register" method to register at the 
begining of the app. The second parameter of the app is a the success 
handler function, and it's executed when response is received. That's 
fine, but later there is a point of the app that user can change the 
registration to another group of categories, and I call it the same way, 
but success method is not executed.

In the server (aerogear) the category is changed and the 200 response is 
sent. Everything seems to work ok but success method not fired. I 
remember that this behaviour didn't happen in earlier versions. Now I'm 
with the 2.0.3. I'm building for android.

Anybody seeing this behaviour too?



-- 

Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
====================
Universitat de Lleida

?rea de sistemes d'Informaci? i Comunicacions

Analista/Programador


University of Lleida

Information and Communication Systems Service


Tlf: +34 973 702148

Fax: +34 973 702130

=====================

Av?s legal/Aviso legal/Avertiment legal/Legal notice 
<http://www.imatge.udl.cat/avis_legal_lopd.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151127/bc20797e/attachment.html 

From alexandre.balleste at udl.cat  Fri Nov 27 05:55:37 2015
From: alexandre.balleste at udl.cat (=?windows-1252?Q?Alex_Ballest=E9?=)
Date: Fri, 27 Nov 2015 11:55:37 +0100
Subject: [Aerogear-users] Push registration with cordova plugin
In-Reply-To: <56581AB7.8020808@udl.cat>
References: <56581AB7.8020808@udl.cat>
Message-ID: <565836A9.60704@udl.cat>

To add some light, in ios it works.

El 27/11/15 a les 09:56, Alex Ballest? ha escrit:
> Hi, I'm a bit disconcerted about a behaviour of push cordova plugin.
>
> What I'm doing is to use the "register" method to register at the 
> begining of the app. The second parameter of the app is a the success 
> handler function, and it's executed when response is received. That's 
> fine, but later there is a point of the app that user can change the 
> registration to another group of categories, and I call it the same 
> way, but success method is not executed.
>
> In the server (aerogear) the category is changed and the 200 response 
> is sent. Everything seems to work ok but success method not fired. I 
> remember that this behaviour didn't happen in earlier versions. Now 
> I'm with the 2.0.3. I'm building for android.
>
> Anybody seeing this behaviour too?
>
>
>
> -- 
>
> Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> ?rea de sistemes d'Informaci? i Comunicacions
>
> Analista/Programador
>
>
> University of Lleida
>
> Information and Communication Systems Service
>
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Av?s legal/Aviso legal/Avertiment legal/Legal notice 
> <http://www.imatge.udl.cat/avis_legal_lopd.html>
>
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users


-- 

Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
====================
Universitat de Lleida

?rea de sistemes d'Informaci? i Comunicacions

Analista/Programador


University of Lleida

Information and Communication Systems Service


Tlf: +34 973 702148

Fax: +34 973 702130

=====================

Av?s legal/Aviso legal/Avertiment legal/Legal notice 
<http://www.imatge.udl.cat/avis_legal_lopd.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151127/e0a2717c/attachment.html 

From spadovani at powowbox.com  Sun Nov 29 06:05:17 2015
From: spadovani at powowbox.com (spi100)
Date: Sun, 29 Nov 2015 04:05:17 -0700 (MST)
Subject: [Aerogear-users] [openshift] Unable to resolve realm public key
 remotely, status = 404
Message-ID: <1448795117702-314.post@n5.nabble.com>

Hi, 
I try to run the openshift cartridge. I have 'server Internal error' when I 
open https://aerogear-powowbox.rhcloud.com/ag-push/

In the log : Unable to resolve realm public key remotely, status = 404

Have someone got any idea ?





--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/openshift-Unable-to-resolve-realm-public-key-remotely-status-404-tp314.html
Sent from the aerogear-users mailing list archive at Nabble.com.

From rwillett at robertwillett.com  Thu Nov 26 14:02:22 2015
From: rwillett at robertwillett.com (Rob Willett)
Date: Thu, 26 Nov 2015 19:02:22 +0000
Subject: [Aerogear-users] Trouble sending Android Push Notifications
 [Solved]
In-Reply-To: <CAD_dpu2pzWguAcJhNPFHJ75vhNmQ496H4BrtDeEiyoMp7i60Pg@mail.gmail.com>
References: <A496F5B4-A8E6-4B9D-8A77-C04D5F347C9F@robertwillett.com>
	<CADF=h2scz1H6mrrsCMpVg=BfDw+fUXYXTV-kLm6xySJZffMang@mail.gmail.com>
	<CAD_dpu1ypAaxzqMGjR5y-nZpTrsLU2d-4SGLNQjiH8x7V2RH5g@mail.gmail.com>
	<BA8854A1-072A-4B16-B524-3B7CEAB283F5@robertwillett.com>
	<CAD_dpu1Efe_fdj24sNo-rTAJS4Om7L-knmt3ZVY7WB4VTphSHw@mail.gmail.com>
	<D6F9E760-E031-4A7A-B277-B10DD17BB3E1@robertwillett.com>
	<7909D286-91DD-4612-BF23-7D703725519C@robertwillett.com>
	<CAD_dpu2pzWguAcJhNPFHJ75vhNmQ496H4BrtDeEiyoMp7i60Pg@mail.gmail.com>
Message-ID: <2E2AC2E8-DF8C-4587-A866-B6E5E262B88E@robertwillett.com>

Sebastien,

Unclear to me what needs to be done.

If its client side then we need to understand what we do to deregister 
and register. e.g. do we do this overtime the user starts the app? That 
doesn?t feel right, though thats just a feeling with nothing to back 
it up.

It feels like this should be a server side activity, though thats not 
because I?m trying to avoid work. I have no idea what the problem is 
(or even if there is a problem). It may well be we have misunderstood 
what needs to happen. I am certainly no expert on Push notifications 
(though we do know an awful lot more than this morning).

We?re putting things on hold for four days as we have a vacation here, 
so we?ll do nothing until Tuesday now. After the last 24 hours I want 
a break to be honest :)

Happy to test ideas out or code, please ask if necessary.

Rob.

On 26 Nov 2015, at 17:01, Sebastien Blanc wrote:

> Great to hear ! And looks like my previous answer was sent while you 
> were
> sending this answer :)
>
> As said in my previous answer, we have some running jobs that cleans 
> up
> invalid tokens but seeing your issues we need to make that more 
> robust, at
> least on our side because maybe things are getting wrong on Google's 
> side
> as well.
>
>
>
> On Thu, Nov 26, 2015 at 5:56 PM, Rob Willett 
> <rob.aerogear at robertwillett.com
>> wrote:
>
>> Got the problem.
>>
>> The device token that was being reported by the UPS Push Console was
>> invalid or out of date.
>>
>> We wrote a quick JavaScript script to register the device and then
>> unregister it.
>>
>> We then forced our app to register again. The device token was 
>> changed
>> in the UPS console variant. We tried to do a Send Push from the 
>> console
>> and it came
>> through fine.
>>
>> We now can see notifications :)
>>
>> Of course its almost the last thing we tried?
>>
>> Now the issue is should the UPS server have got a new device token if
>> the variant was deleted AND the GCM project was deleted? We are not
>> clear when the device token is renewed but either
>>
>> 1. The UPS server should do this automatically when variants are 
>> deleted
>> or some other way of detecting that things have changed.
>>
>> OR
>>
>> 2. Should the app do it. In which case when should push.unregister() 
>> be
>> called. Should we unregister and register every time the app starts 
>> up
>> to make sure the device token is valid. Seems excessive which is why 
>> my
>> first thought is that this should be server side not client side.
>>
>> I don?t know what the answer is, but stale Android device tokens 
>> have
>> been an issue for us. The fact they survive multiple different Google
>> Projects AND multiple different UPS variants makes me think this is 
>> an
>> issue.
>>
>> Anybody care to comment?
>>
>> Rob (who is now going got a coffee as he?s earn it)
>>
>> On 26 Nov 2015, at 16:35, Rob Willett wrote:
>>
>>> Sebastien,
>>>
>>> Well we have created and deleted variants and various Google 
>>> Projects
>>> all with the result. No notification but no errors.
>>>
>>> We have validated the server API key using another curl script
>>>
>>> We have managed to write a curl script that almost works but not 
>>> quite
>>> :) We get a MismatchSenderId error.
>>>
>>> Grepping for this on the intertubes shows a lot of Stackoverflow
>>> nonsense and some stuff from Google.
>>>
>>> What we are now wondering if the device token that we are using, 
>>> that
>>> reported by the AeroGear UPS console is actually out of date.
>>>
>>> When we delete the variant we create a new variant and register with
>>> that. The device token created and reported by the UPS console is 
>>> the
>>> same as the old variant. We are wondering if this is incorrect and 
>>> it
>>> should be a new device token. We?re trying to delete it but you
>>> can?t seem to delete it from the console and trying to delete it
>>> from
>>> our app calls the Javascript error function.
>>>
>>> We?ll keep trying, but our other Android phone packed up yesterday
>>> and
>>> we only one left. We?re pulling out an old Samsung S3 on the off
>>> chance it might work :)
>>>
>>> Any thoughts on invalid device tokens?
>>>
>>> Rob
>>>
>>>>> I can?t believe that we have missed a simple configuration issue
>>>>> on
>>>>> the
>>>>> UnifiedPush server.
>>>>>
>>>> Yes, strange, looks like you are doing everything the correct way
>>>>
>>>>> We?ll try and bypass the UPS console and write direct to GCM now
>>>>> through
>>>>> curl or something. Do you know if the device token in the UPS
>>>>> console
>>>>> is
>>>>> the Android token to use?
>>>>>
>>>> That is good test indeed and yes the token in UPS is the one you 
>>>> can
>>>> use
>>>> for your GCM test.
>>>>
>>>>> Thanks
>>>
>>> _______________________________________________
>>> Aerogear-users mailing list
>>> Aerogear-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> _______________________________________________
>> Aerogear-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users

From jeffpower78 at gmail.com  Fri Nov 27 05:49:20 2015
From: jeffpower78 at gmail.com (jeffpower78)
Date: Fri, 27 Nov 2015 03:49:20 -0700 (MST)
Subject: [Aerogear-users] Mobile SSO - web brower+ native iOS
Message-ID: <1448621360546-312.post@n5.nabble.com>

we have a situation where users have applications  both html5 based web and
also native iOS apps accessing from iPads

The requirement is that users access the web based application within a
iPad, which will be redirected to central server for login.
Once user logins, next time, if the same user just tap on the native app
within the same device, it should not again prompt for userid/password,
rather SSO takes care of it

We need to design  so that users can toggle back and forth among mobile
browser apps and mobile apps.
This is ideal for agents, sales reps, who to need to switch quickly among
programs while on the go.,

Would like to know - is this something aerogear security supports please or
any suggestion, advice?

Thanks and Regards
Jeff



--
View this message in context: http://aerogear-users.1116366.n5.nabble.com/Mobile-SSO-web-brower-native-iOS-tp312.html
Sent from the aerogear-users mailing list archive at Nabble.com.

From matzew at apache.org  Mon Nov 30 06:13:37 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 30 Nov 2015 12:13:37 +0100
Subject: [Aerogear-users] [openshift] Unable to resolve realm public key
 remotely, status = 404
In-Reply-To: <1448795117702-314.post@n5.nabble.com>
References: <1448795117702-314.post@n5.nabble.com>
Message-ID: <CAAg5f2SMtD7tiGazZWN1upJqTSp4zr7BWm=TVpJHhonpaEF6Yg@mail.gmail.com>

Did you create it using a medium sized gear?

https://github.com/aerogear/openshift-origin-cartridge-aerogear-push#installation

-M

On Sun, Nov 29, 2015 at 12:05 PM, spi100 <spadovani at powowbox.com> wrote:

> Hi,
> I try to run the openshift cartridge. I have 'server Internal error' when I
> open https://aerogear-powowbox.rhcloud.com/ag-push/
>
> In the log : Unable to resolve realm public key remotely, status = 404
>
> Have someone got any idea ?
>
>
>
>
>
> --
> View this message in context:
> http://aerogear-users.1116366.n5.nabble.com/openshift-Unable-to-resolve-realm-public-key-remotely-status-404-tp314.html
> Sent from the aerogear-users mailing list archive at Nabble.com.
> _______________________________________________
> 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-users/attachments/20151130/8773468a/attachment.html 

From edewit at redhat.com  Mon Nov 30 09:02:51 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Mon, 30 Nov 2015 15:02:51 +0100
Subject: [Aerogear-users] Push registration with cordova plugin
In-Reply-To: <565836A9.60704@udl.cat>
References: <56581AB7.8020808@udl.cat>
	<565836A9.60704@udl.cat>
Message-ID: <CAO2B-fa0R9YA4YjrF0atsaAtzyiywipnhqoNqtEGAnUCQ1dDiQ@mail.gmail.com>

Hi Alex,

Yes this is a bug in the android part of the cordova push plugin. I've
created an issue AGCORDOVA-125 [1] and a fix PR [2], could you try and see
if it works? Instructions on how to try the fix are on the PR.

[1] https://issues.jboss.org/browse/AGCORDOVA-125
[2] https://github.com/aerogear/aerogear-cordova-push/pull/82

On Fri, Nov 27, 2015 at 11:55 AM, Alex Ballest? <alexandre.balleste at udl.cat>
wrote:

> To add some light, in ios it works.
>
> El 27/11/15 a les 09:56, Alex Ballest? ha escrit:
>
> Hi, I'm a bit disconcerted about a behaviour of push cordova plugin.
>
> What I'm doing is to use the "register" method to register at the begining
> of the app. The second parameter of the app is a the success handler
> function, and it's executed when response is received. That's fine, but
> later there is a point of the app that user can change the registration to
> another group of categories, and I call it the same way, but success method
> is not executed.
>
> In the server (aerogear) the category is changed and the 200 response is
> sent. Everything seems to work ok but success method not fired. I remember
> that this behaviour didn't happen in earlier versions. Now I'm with the
> 2.0.3. I'm building for android.
>
> Anybody seeing this behaviour too?
>
>
>
> --
>
> Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> ?rea de sistemes d'Informaci? i Comunicacions
>
> Analista/Programador
>
> University of Lleida
>
> Information and Communication Systems Service
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Av?s legal/Aviso legal/Avertiment legal/Legal notice
> <http://www.imatge.udl.cat/avis_legal_lopd.html>
>
>
> _______________________________________________
> Aerogear-users mailing listAerogear-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
>
> --
>
> Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> ?rea de sistemes d'Informaci? i Comunicacions
>
> Analista/Programador
>
> University of Lleida
>
> Information and Communication Systems Service
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Av?s legal/Aviso legal/Avertiment legal/Legal notice
> <http://www.imatge.udl.cat/avis_legal_lopd.html>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>


-- 
Cheers,
       Erik Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151130/461e0c00/attachment.html 

From alexandre.balleste at udl.cat  Mon Nov 30 09:11:39 2015
From: alexandre.balleste at udl.cat (=?windows-1252?Q?Alex_Ballest=E9?=)
Date: Mon, 30 Nov 2015 15:11:39 +0100
Subject: [Aerogear-users] Push registration with cordova plugin
In-Reply-To: <CAO2B-fa0R9YA4YjrF0atsaAtzyiywipnhqoNqtEGAnUCQ1dDiQ@mail.gmail.com>
References: <56581AB7.8020808@udl.cat>	<565836A9.60704@udl.cat>
	<CAO2B-fa0R9YA4YjrF0atsaAtzyiywipnhqoNqtEGAnUCQ1dDiQ@mail.gmail.com>
Message-ID: <565C591B.4060609@udl.cat>

Sure, I'll test it tomorrow morning. It has been a very quick response. 
Great.

Thanks.

Alex.

El 30/11/15 a les 15:02, Erik Jan de Wit ha escrit:
> Hi Alex,
>
> Yes this is a bug in the android part of the cordova push plugin. I've 
> created an issue AGCORDOVA-125 [1] and a fix PR [2], could you try and 
> see if it works? Instructions on how to try the fix are on the PR.
>
> [1] https://issues.jboss.org/browse/AGCORDOVA-125
> [2] https://github.com/aerogear/aerogear-cordova-push/pull/82
>
> On Fri, Nov 27, 2015 at 11:55 AM, Alex Ballest? 
> <alexandre.balleste at udl.cat <mailto:alexandre.balleste at udl.cat>> wrote:
>
>     To add some light, in ios it works.
>
>     El 27/11/15 a les 09:56, Alex Ballest? ha escrit:
>>     Hi, I'm a bit disconcerted about a behaviour of push cordova plugin.
>>
>>     What I'm doing is to use the "register" method to register at the
>>     begining of the app. The second parameter of the app is a the
>>     success handler function, and it's executed when response is
>>     received. That's fine, but later there is a point of the app that
>>     user can change the registration to another group of categories,
>>     and I call it the same way, but success method is not executed.
>>
>>     In the server (aerogear) the category is changed and the 200
>>     response is sent. Everything seems to work ok but success method
>>     not fired. I remember that this behaviour didn't happen in
>>     earlier versions. Now I'm with the 2.0.3. I'm building for android.
>>
>>     Anybody seeing this behaviour too?
>>
>>
>>
>>     -- 
>>
>>     Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
>>     <http://udl.cat>
>>     ====================
>>     Universitat de Lleida
>>
>>     ?rea de sistemes d'Informaci? i Comunicacions
>>
>>     Analista/Programador
>>
>>
>>     University of Lleida
>>
>>     Information and Communication Systems Service
>>
>>
>>     Tlf: +34 973 702148 <tel:%2B34%20973%20702148>
>>
>>     Fax: +34 973 702130 <tel:%2B34%20973%20702130>
>>
>>     =====================
>>
>>     Av?s legal/Aviso legal/Avertiment legal/Legal notice
>>     <http://www.imatge.udl.cat/avis_legal_lopd.html>
>>
>>
>>
>>     _______________________________________________
>>     Aerogear-users mailing list
>>     Aerogear-users at lists.jboss.org  <mailto:Aerogear-users at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
>     -- 
>
>     Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
>     <http://udl.cat>
>     ====================
>     Universitat de Lleida
>
>     ?rea de sistemes d'Informaci? i Comunicacions
>
>     Analista/Programador
>
>
>     University of Lleida
>
>     Information and Communication Systems Service
>
>
>     Tlf: +34 973 702148 <tel:%2B34%20973%20702148>
>
>     Fax: +34 973 702130 <tel:%2B34%20973%20702130>
>
>     =====================
>
>     Av?s legal/Aviso legal/Avertiment legal/Legal notice
>     <http://www.imatge.udl.cat/avis_legal_lopd.html>
>
>
>     _______________________________________________
>     Aerogear-users mailing list
>     Aerogear-users at lists.jboss.org <mailto:Aerogear-users at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
>
>
> -- 
> Cheers,
>        Erik Jan
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users


-- 

Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
====================
Universitat de Lleida

?rea de sistemes d'Informaci? i Comunicacions

Analista/Programador


University of Lleida

Information and Communication Systems Service


Tlf: +34 973 702148

Fax: +34 973 702130

=====================

Av?s legal/Aviso legal/Avertiment legal/Legal notice 
<http://www.imatge.udl.cat/avis_legal_lopd.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151130/c8523bf4/attachment-0001.html