From alexandre.balleste at udl.cat Tue Dec 1 02:15:24 2015 From: alexandre.balleste at udl.cat (=?windows-1252?Q?Alex_Ballest=E9?=) Date: Tue, 01 Dec 2015 08:15:24 +0100 Subject: [Aerogear-users] Push registration with cordova plugin In-Reply-To: <565C591B.4060609@udl.cat> References: <56581AB7.8020808@udl.cat> <565836A9.60704@udl.cat> <565C591B.4060609@udl.cat> Message-ID: <565D490C.4010904@udl.cat> Yeah, it works. Thank you again. Alex. El 30/11/15 a les 15:11, Alex Ballest? ha escrit: > 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? >> > 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 >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 > > > -- > > 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 > > > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151201/93506e13/attachment.html From edewit at redhat.com Tue Dec 1 02:22:35 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 1 Dec 2015 08:22:35 +0100 Subject: [Aerogear-users] Push registration with cordova plugin In-Reply-To: <565D490C.4010904@udl.cat> References: <56581AB7.8020808@udl.cat> <565836A9.60704@udl.cat> <565C591B.4060609@udl.cat> <565D490C.4010904@udl.cat> Message-ID: Super, I merged the PR it will be part of version 2.0.4 On Tue, Dec 1, 2015 at 8:15 AM, Alex Ballest? wrote: > Yeah, it works. Thank you again. > > Alex. > > El 30/11/15 a les 15:11, Alex Ballest? ha escrit: > > 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> 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 <%2B34%20973%20702148> >> >> Fax: +34 973 702130 <%2B34%20973%20702130> >> >> ===================== >> >> Av?s legal/Aviso legal/Avertiment legal/Legal notice >> >> >> >> _______________________________________________ >> 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 <%2B34%20973%20702148> >> >> Fax: +34 973 702130 <%2B34%20973%20702130> >> >> ===================== >> >> Av?s legal/Aviso legal/Avertiment legal/Legal notice >> >> >> _______________________________________________ >> Aerogear-users mailing list >> Aerogear-users at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-users >> >> > > > -- > Cheers, > Erik Jan > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > > > _______________________________________________ > 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/20151201/67249ac2/attachment-0001.html From gunther.klein at f24.com Tue Dec 1 14:05:00 2015 From: gunther.klein at f24.com (gklein) Date: Tue, 1 Dec 2015 12:05:00 -0700 (MST) Subject: [Aerogear-users] Aerogear UPS 1.1.0.Final max. number of aliases in push notification request Message-ID: <1448996700098-321.post@n5.nabble.com> Hi! When we send a push message with a very big list of aliases to Aerogear-1.1.0 (25k aliases), we can see a strack trace in the server logs, indicating a low level postgres db exception ('ERROR: value too long for type character varying(4500)'). So obviously the calling client seems having to take care of proper validation and e.g. breaking the request up into smaller batches. Right? So, whats the actual number of aliases, that can be specified in one push notification batch request? Also: Wouldn't a proper validation check on the server side make sense, before persisting to the db? Regards, Gunther --- stack trace --- 2015-12-01 18:08:44,239 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) SQL Error: 0, SQLState: 22001 2015-12-01 18:08:44,239 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) ERROR: value too long for type character varying(4500) 2015-12-01 18:08:44,239 INFO [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default task-12) HHH000010: On release of batch it still contained JDBC statements 2015-12-01 18:08:44,240 ERROR [org.jboss.as.ejb3] (default task-12) javax.ejb.EJBTransactionRolledbackException: org.hibernate.exception.DataException: could not execute statement 2015-12-01 18:08:44,240 ERROR [org.jboss.as.ejb3.invocation] (default task-12) JBAS014134: EJB Invocation failed on component PushMessageMetricsService for method public org.jboss.aerogear.unifiedpush.api.PushMessageInformation org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService.storeNewRequestFrom(java.lang.String,java.lang.String,java.lang.String,java.lang.String,int): javax.ejb.EJBTransactionRolledbackException: org.hibernate.exception.DataException: could not execute statement at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:439) 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.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService$$$view8.storeNewRequestFrom(Unknown Source) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source) [:1.8.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45] at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45] at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService$Proxy$_$$_Weld$EnterpriseProxy$.storeNewRequestFrom(Unknown Source) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] at org.jboss.aerogear.unifiedpush.message.NotificationRouter.submit(NotificationRouter.java:101) [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.8.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45] at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45] 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.2.0.Final.jar:8.2.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:46) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.jboss.aerogear.unifiedpush.message.NotificationRouter$$$view20.submit(Unknown Source) [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.8.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45] at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45] at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.aerogear.unifiedpush.message.NotificationRouter$Proxy$_$$_Weld$EnterpriseProxy$.submit(Unknown Source) [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] at org.jboss.aerogear.unifiedpush.rest.sender.PushNotificationSenderEndpoint.send(PushNotificationSenderEndpoint.java:107) [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] at org.jboss.aerogear.unifiedpush.rest.sender.PushNotificationSenderEndpoint$Proxy$_$$_WeldClientProxy.send(Unknown Source) [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] at sun.reflect.GeneratedMethodAccessor385.invoke(Unknown Source) [:1.8.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45] at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.10.Final.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at org.jboss.aerogear.unifiedpush.service.filter.HttpContextFilter.doFilter(HttpContextFilter.java:55) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at org.jboss.aerogear.unifiedpush.rest.util.VersionFilter.doFilter(VersionFilter.java:65) [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] at org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] Caused by: javax.persistence.PersistenceException: org.hibernate.exception.DataException: could not execute statement at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1683) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1338) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] at org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:457) [wildfly-jpa-8.2.0.Final.jar:8.2.0.Final] at sun.reflect.GeneratedMethodAccessor339.invoke(Unknown Source) [:1.8.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45] at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45] at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:42) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weldx.persistence.EntityManager$1602193877$Proxy$_$$_Weld$Proxy$.flush(Unknown Source) [hibernate-jpa-2.1-api-1.0.0.Final.jar:] at org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPABaseDao.flushAndClear(JPABaseDao.java:102) [unifiedpush-model-jpa-1.1.0.Final.jar:1.1.0.Final] at org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService.storeNewRequestFrom(PushMessageMetricsService.java:70) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source) [:1.8.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45] at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45] 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.2.0.Final.jar:8.2.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:46) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] ... 174 more Caused by: org.hibernate.exception.DataException: could not execute statement at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:135) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3124) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3581) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:104) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1335) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] ... 219 more Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(4500) at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2270) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1998) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:570) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:420) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:366) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] ... 229 more -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-UPS-1-1-0-Final-max-number-of-aliases-in-push-notification-request-tp321.html Sent from the aerogear-users mailing list archive at Nabble.com. From matzew at apache.org Tue Dec 1 14:28:58 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Dec 2015 20:28:58 +0100 Subject: [Aerogear-users] Aerogear UPS 1.1.0.Final max. number of aliases in push notification request In-Reply-To: <1448996700098-321.post@n5.nabble.com> References: <1448996700098-321.post@n5.nabble.com> Message-ID: Hi G?nther, thanks for reaching out ob this. I agree its a pretty lame bug! Will look into it tomorrow. Sorry for the inconvenience On Tuesday, 1 December 2015, gklein wrote: > Hi! > > When we send a push message with a very big list of aliases to > Aerogear-1.1.0 (25k aliases), we can see a strack trace in the server logs, > indicating a low level postgres db exception ('ERROR: value too long for > type character varying(4500)'). So obviously the calling client seems > having > to take care of proper validation and e.g. breaking the request up into > smaller batches. Right? So, whats the actual number of aliases, that can be > specified in one push notification batch request? Also: Wouldn't a proper > validation check on the server side make sense, before persisting to the > db? > > Regards, Gunther > > > --- stack trace --- > 2015-12-01 18:08:44,239 WARN > [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) SQL > Error: 0, SQLState: 22001 > 2015-12-01 18:08:44,239 ERROR > [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) ERROR: > value too long for type character varying(4500) > 2015-12-01 18:08:44,239 INFO > [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default > task-12) HHH000010: On release of batch it still contained JDBC statements > 2015-12-01 18:08:44,240 ERROR [org.jboss.as.ejb3] (default task-12) > javax.ejb.EJBTransactionRolledbackException: > org.hibernate.exception.DataException: could not execute statement > 2015-12-01 18:08:44,240 ERROR [org.jboss.as.ejb3.invocation] (default > task-12) JBAS014134: EJB Invocation failed on component > PushMessageMetricsService for method public > org.jboss.aerogear.unifiedpush.api.PushMessageInformation > > org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService.storeNewRequestFrom(java.lang.String,java.lang.String,java.lang.String,java.lang.String,int): > javax.ejb.EJBTransactionRolledbackException: > org.hibernate.exception.DataException: could not execute statement > at > > org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) > [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] > at > > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) > [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) > [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] > at > > org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > [wildfly-ejb3-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:439) > 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.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at > > org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at > > org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService$$$view8.storeNewRequestFrom(Unknown > Source) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] > at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source) > [:1.8.0_45] > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.8.0_45] > at java.lang.reflect.Method.invoke(Method.java:497) > [rt.jar:1.8.0_45] > at > > org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService$Proxy$_$$_Weld$EnterpriseProxy$.storeNewRequestFrom(Unknown > Source) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] > at > > org.jboss.aerogear.unifiedpush.message.NotificationRouter.submit(NotificationRouter.java:101) > [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] > at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) > [:1.8.0_45] > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.8.0_45] > at java.lang.reflect.Method.invoke(Method.java:497) > [rt.jar:1.8.0_45] > 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.2.0.Final.jar:8.2.0.Final] > at > > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:46) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.0.Final] > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) > [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] > at > > org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > [wildfly-ejb3-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at > > org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at > > org.jboss.aerogear.unifiedpush.message.NotificationRouter$$$view20.submit(Unknown > Source) [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] > at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) > [:1.8.0_45] > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.8.0_45] > at java.lang.reflect.Method.invoke(Method.java:497) > [rt.jar:1.8.0_45] > at > > org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.aerogear.unifiedpush.message.NotificationRouter$Proxy$_$$_Weld$EnterpriseProxy$.submit(Unknown > Source) [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] > at > > org.jboss.aerogear.unifiedpush.rest.sender.PushNotificationSenderEndpoint.send(PushNotificationSenderEndpoint.java:107) > [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] > at > > org.jboss.aerogear.unifiedpush.rest.sender.PushNotificationSenderEndpoint$Proxy$_$$_WeldClientProxy.send(Unknown > Source) [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] > at sun.reflect.GeneratedMethodAccessor385.invoke(Unknown Source) > [:1.8.0_45] > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.8.0_45] > at java.lang.reflect.Method.invoke(Method.java:497) > [rt.jar:1.8.0_45] > at > > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > [resteasy-jaxrs-3.0.10.Final.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at > > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > org.jboss.aerogear.unifiedpush.service.filter.HttpContextFilter.doFilter(HttpContextFilter.java:55) > [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > org.jboss.aerogear.unifiedpush.rest.util.VersionFilter.doFilter(VersionFilter.java:65) > [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) > [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] > at > > org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) > [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] > at > > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] > at > > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] > at > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [rt.jar:1.8.0_45] > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [rt.jar:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > Caused by: javax.persistence.PersistenceException: > org.hibernate.exception.DataException: could not execute statement > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) > [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) > [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1683) > [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1338) > [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at > > org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:457) > [wildfly-jpa-8.2.0.Final.jar:8.2.0.Final] > at sun.reflect.GeneratedMethodAccessor339.invoke(Unknown Source) > [:1.8.0_45] > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.8.0_45] > at java.lang.reflect.Method.invoke(Method.java:497) > [rt.jar:1.8.0_45] > at > > org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:42) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.weldx.persistence.EntityManager$1602193877$Proxy$_$$_Weld$Proxy$.flush(Unknown > Source) [hibernate-jpa-2.1-api-1.0.0.Final.jar:] > at > > org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPABaseDao.flushAndClear(JPABaseDao.java:102) > [unifiedpush-model-jpa-1.1.0.Final.jar:1.1.0.Final] > at > > org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService.storeNewRequestFrom(PushMessageMetricsService.java:70) > [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] > at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source) > [:1.8.0_45] > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.8.0_45] > at java.lang.reflect.Method.invoke(Method.java:497) > [rt.jar:1.8.0_45] > 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.2.0.Final.jar:8.2.0.Final] > at > > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:46) > [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] > at > > org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.0.Final] > at > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at > > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) > [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] > ... 174 more > Caused by: org.hibernate.exception.DataException: could not execute > statement > at > > org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:135) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3124) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3581) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:104) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1335) > [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > ... 219 more > Caused by: org.postgresql.util.PSQLException: ERROR: value too long for > type > character varying(4500) > at > > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2270) > at > > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1998) > at > > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) > at > > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:570) > at > > org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:420) > at > > org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:366) > at > > org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) > at > > org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > ... 229 more > > > > > -- > View this message in context: > http://aerogear-users.1116366.n5.nabble.com/Aerogear-UPS-1-1-0-Final-max-number-of-aliases-in-push-notification-request-tp321.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 > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151201/143cba4e/attachment-0001.html From matzew at apache.org Tue Dec 1 15:36:39 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Dec 2015 21:36:39 +0100 Subject: [Aerogear-users] Aerogear UPS 1.1.0.Final max. number of aliases in push notification request In-Reply-To: References: <1448996700098-321.post@n5.nabble.com> Message-ID: I think we won't be storing the raw JSON, and likely remove the alias data On Tue, Dec 1, 2015 at 8:28 PM, Matthias Wessendorf wrote: > Hi G?nther, > > thanks for reaching out ob this. I agree its a pretty lame bug! > > Will look into it tomorrow. Sorry for the inconvenience > > On Tuesday, 1 December 2015, gklein wrote: > >> Hi! >> >> When we send a push message with a very big list of aliases to >> Aerogear-1.1.0 (25k aliases), we can see a strack trace in the server >> logs, >> indicating a low level postgres db exception ('ERROR: value too long for >> type character varying(4500)'). So obviously the calling client seems >> having >> to take care of proper validation and e.g. breaking the request up into >> smaller batches. Right? So, whats the actual number of aliases, that can >> be >> specified in one push notification batch request? Also: Wouldn't a proper >> validation check on the server side make sense, before persisting to the >> db? >> >> Regards, Gunther >> >> >> --- stack trace --- >> 2015-12-01 18:08:44,239 WARN >> [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) SQL >> Error: 0, SQLState: 22001 >> 2015-12-01 18:08:44,239 ERROR >> [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) >> ERROR: >> value too long for type character varying(4500) >> 2015-12-01 18:08:44,239 INFO >> [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default >> task-12) HHH000010: On release of batch it still contained JDBC statements >> 2015-12-01 18:08:44,240 ERROR [org.jboss.as.ejb3] (default task-12) >> javax.ejb.EJBTransactionRolledbackException: >> org.hibernate.exception.DataException: could not execute statement >> 2015-12-01 18:08:44,240 ERROR [org.jboss.as.ejb3.invocation] (default >> task-12) JBAS014134: EJB Invocation failed on component >> PushMessageMetricsService for method public >> org.jboss.aerogear.unifiedpush.api.PushMessageInformation >> >> org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService.storeNewRequestFrom(java.lang.String,java.lang.String,java.lang.String,java.lang.String,int): >> javax.ejb.EJBTransactionRolledbackException: >> org.hibernate.exception.DataException: could not execute statement >> at >> >> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) >> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >> at >> >> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) >> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >> at >> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) >> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >> at >> >> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) >> [wildfly-ejb3-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:439) >> 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.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at >> >> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) >> at >> >> org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService$$$view8.storeNewRequestFrom(Unknown >> Source) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] >> at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source) >> [:1.8.0_45] >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> [rt.jar:1.8.0_45] >> at java.lang.reflect.Method.invoke(Method.java:497) >> [rt.jar:1.8.0_45] >> at >> >> org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService$Proxy$_$$_Weld$EnterpriseProxy$.storeNewRequestFrom(Unknown >> Source) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.jboss.aerogear.unifiedpush.message.NotificationRouter.submit(NotificationRouter.java:101) >> [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] >> at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) >> [:1.8.0_45] >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> [rt.jar:1.8.0_45] >> at java.lang.reflect.Method.invoke(Method.java:497) >> [rt.jar:1.8.0_45] >> 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.2.0.Final.jar:8.2.0.Final] >> at >> >> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) >> [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:46) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) >> [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.0.Final] >> at >> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) >> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >> at >> >> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) >> [wildfly-ejb3-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at >> >> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) >> at >> >> org.jboss.aerogear.unifiedpush.message.NotificationRouter$$$view20.submit(Unknown >> Source) [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] >> at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) >> [:1.8.0_45] >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> [rt.jar:1.8.0_45] >> at java.lang.reflect.Method.invoke(Method.java:497) >> [rt.jar:1.8.0_45] >> at >> >> org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.aerogear.unifiedpush.message.NotificationRouter$Proxy$_$$_Weld$EnterpriseProxy$.submit(Unknown >> Source) [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.jboss.aerogear.unifiedpush.rest.sender.PushNotificationSenderEndpoint.send(PushNotificationSenderEndpoint.java:107) >> [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.jboss.aerogear.unifiedpush.rest.sender.PushNotificationSenderEndpoint$Proxy$_$$_WeldClientProxy.send(Unknown >> Source) [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] >> at sun.reflect.GeneratedMethodAccessor385.invoke(Unknown Source) >> [:1.8.0_45] >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> [rt.jar:1.8.0_45] >> at java.lang.reflect.Method.invoke(Method.java:497) >> [rt.jar:1.8.0_45] >> at >> >> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) >> [resteasy-jaxrs-3.0.10.Final.jar:] >> at >> >> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) >> [resteasy-jaxrs-3.0.10.Final.jar:] >> at >> >> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) >> [resteasy-jaxrs-3.0.10.Final.jar:] >> at >> >> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) >> [resteasy-jaxrs-3.0.10.Final.jar:] >> at >> >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) >> [resteasy-jaxrs-3.0.10.Final.jar:] >> at >> >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) >> [resteasy-jaxrs-3.0.10.Final.jar:] >> at >> >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) >> [resteasy-jaxrs-3.0.10.Final.jar:] >> at >> >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >> [resteasy-jaxrs-3.0.10.Final.jar:] >> at >> >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >> [resteasy-jaxrs-3.0.10.Final.jar:] >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.jboss.aerogear.unifiedpush.service.filter.HttpContextFilter.doFilter(HttpContextFilter.java:55) >> [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] >> at >> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.jboss.aerogear.unifiedpush.rest.util.VersionFilter.doFilter(VersionFilter.java:65) >> [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] >> at >> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) >> [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] >> at >> >> org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) >> [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] >> at >> >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >> [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] >> at >> >> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >> [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] >> at >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> [rt.jar:1.8.0_45] >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> [rt.jar:1.8.0_45] >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] >> Caused by: javax.persistence.PersistenceException: >> org.hibernate.exception.DataException: could not execute statement >> at >> >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) >> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) >> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java: >> 1683) >> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1338) >> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:457) >> [wildfly-jpa-8.2.0.Final.jar:8.2.0.Final] >> at sun.reflect.GeneratedMethodAccessor339.invoke(Unknown Source) >> [:1.8.0_45] >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> [rt.jar:1.8.0_45] >> at java.lang.reflect.Method.invoke(Method.java:497) >> [rt.jar:1.8.0_45] >> at >> >> org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:42) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.weldx.persistence.EntityManager$1602193877$Proxy$_$$_Weld$Proxy$.flush(Unknown >> Source) [hibernate-jpa-2.1-api-1.0.0.Final.jar:] >> at >> >> org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPABaseDao.flushAndClear(JPABaseDao.java:102) >> [unifiedpush-model-jpa-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService.storeNewRequestFrom(PushMessageMetricsService.java:70) >> [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] >> at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source) >> [:1.8.0_45] >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> [rt.jar:1.8.0_45] >> at java.lang.reflect.Method.invoke(Method.java:497) >> [rt.jar:1.8.0_45] >> 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.2.0.Final.jar:8.2.0.Final] >> at >> >> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) >> [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:46) >> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >> at >> >> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) >> [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.0.Final] >> at >> >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) >> at >> >> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) >> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >> ... 174 more >> Caused by: org.hibernate.exception.DataException: could not execute >> statement >> at >> >> org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:135) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3124) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3581) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:104) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1335) >> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> ... 219 more >> Caused by: org.postgresql.util.PSQLException: ERROR: value too long for >> type >> character varying(4500) >> at >> >> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2270) >> at >> >> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1998) >> at >> >> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) >> at >> >> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:570) >> at >> >> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:420) >> at >> >> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:366) >> at >> >> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) >> at >> >> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> ... 229 more >> >> >> >> >> -- >> View this message in context: >> http://aerogear-users.1116366.n5.nabble.com/Aerogear-UPS-1-1-0-Final-max-number-of-aliases-in-push-notification-request-tp321.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 >> > > > -- > Sent from Gmail Mobile > -- 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/20151201/e29d02a9/attachment-0001.html From matzew at apache.org Tue Dec 1 15:57:53 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Dec 2015 21:57:53 +0100 Subject: [Aerogear-users] Aerogear UPS 1.1.0.Final max. number of aliases in push notification request In-Reply-To: References: <1448996700098-321.post@n5.nabble.com> Message-ID: To track it, I created https://issues.jboss.org/browse/AGPUSH-1543 -M On Tue, Dec 1, 2015 at 9:36 PM, Matthias Wessendorf wrote: > I think we won't be storing the raw JSON, and likely remove the alias data > > On Tue, Dec 1, 2015 at 8:28 PM, Matthias Wessendorf > wrote: > >> Hi G?nther, >> >> thanks for reaching out ob this. I agree its a pretty lame bug! >> >> Will look into it tomorrow. Sorry for the inconvenience >> >> On Tuesday, 1 December 2015, gklein wrote: >> >>> Hi! >>> >>> When we send a push message with a very big list of aliases to >>> Aerogear-1.1.0 (25k aliases), we can see a strack trace in the server >>> logs, >>> indicating a low level postgres db exception ('ERROR: value too long for >>> type character varying(4500)'). So obviously the calling client seems >>> having >>> to take care of proper validation and e.g. breaking the request up into >>> smaller batches. Right? So, whats the actual number of aliases, that can >>> be >>> specified in one push notification batch request? Also: Wouldn't a proper >>> validation check on the server side make sense, before persisting to the >>> db? >>> >>> Regards, Gunther >>> >>> >>> --- stack trace --- >>> 2015-12-01 18:08:44,239 WARN >>> [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) SQL >>> Error: 0, SQLState: 22001 >>> 2015-12-01 18:08:44,239 ERROR >>> [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) >>> ERROR: >>> value too long for type character varying(4500) >>> 2015-12-01 18:08:44,239 INFO >>> [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default >>> task-12) HHH000010: On release of batch it still contained JDBC >>> statements >>> 2015-12-01 18:08:44,240 ERROR [org.jboss.as.ejb3] (default task-12) >>> javax.ejb.EJBTransactionRolledbackException: >>> org.hibernate.exception.DataException: could not execute statement >>> 2015-12-01 18:08:44,240 ERROR [org.jboss.as.ejb3.invocation] (default >>> task-12) JBAS014134: EJB Invocation failed on component >>> PushMessageMetricsService for method public >>> org.jboss.aerogear.unifiedpush.api.PushMessageInformation >>> >>> org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService.storeNewRequestFrom(java.lang.String,java.lang.String,java.lang.String,java.lang.String,int): >>> javax.ejb.EJBTransactionRolledbackException: >>> org.hibernate.exception.DataException: could not execute statement >>> at >>> >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) >>> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >>> at >>> >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) >>> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >>> at >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) >>> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >>> at >>> >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) >>> [wildfly-ejb3-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:439) >>> 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.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>> at >>> >>> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) >>> at >>> >>> org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService$$$view8.storeNewRequestFrom(Unknown >>> Source) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] >>> at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source) >>> [:1.8.0_45] >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> [rt.jar:1.8.0_45] >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> [rt.jar:1.8.0_45] >>> at >>> >>> org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService$Proxy$_$$_Weld$EnterpriseProxy$.storeNewRequestFrom(Unknown >>> Source) [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.jboss.aerogear.unifiedpush.message.NotificationRouter.submit(NotificationRouter.java:101) >>> [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] >>> at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) >>> [:1.8.0_45] >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> [rt.jar:1.8.0_45] >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> [rt.jar:1.8.0_45] >>> 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.2.0.Final.jar:8.2.0.Final] >>> at >>> >>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) >>> [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:46) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) >>> [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.0.Final] >>> at >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) >>> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >>> at >>> >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) >>> [wildfly-ejb3-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>> at >>> >>> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) >>> at >>> >>> org.jboss.aerogear.unifiedpush.message.NotificationRouter$$$view20.submit(Unknown >>> Source) [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] >>> at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) >>> [:1.8.0_45] >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> [rt.jar:1.8.0_45] >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> [rt.jar:1.8.0_45] >>> at >>> >>> org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.aerogear.unifiedpush.message.NotificationRouter$Proxy$_$$_Weld$EnterpriseProxy$.submit(Unknown >>> Source) [unifiedpush-push-sender-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.jboss.aerogear.unifiedpush.rest.sender.PushNotificationSenderEndpoint.send(PushNotificationSenderEndpoint.java:107) >>> [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.jboss.aerogear.unifiedpush.rest.sender.PushNotificationSenderEndpoint$Proxy$_$$_WeldClientProxy.send(Unknown >>> Source) [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] >>> at sun.reflect.GeneratedMethodAccessor385.invoke(Unknown Source) >>> [:1.8.0_45] >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> [rt.jar:1.8.0_45] >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> [rt.jar:1.8.0_45] >>> at >>> >>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) >>> [resteasy-jaxrs-3.0.10.Final.jar:] >>> at >>> >>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) >>> [resteasy-jaxrs-3.0.10.Final.jar:] >>> at >>> >>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) >>> [resteasy-jaxrs-3.0.10.Final.jar:] >>> at >>> >>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) >>> [resteasy-jaxrs-3.0.10.Final.jar:] >>> at >>> >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) >>> [resteasy-jaxrs-3.0.10.Final.jar:] >>> at >>> >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) >>> [resteasy-jaxrs-3.0.10.Final.jar:] >>> at >>> >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) >>> [resteasy-jaxrs-3.0.10.Final.jar:] >>> at >>> >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>> [resteasy-jaxrs-3.0.10.Final.jar:] >>> at >>> >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>> [resteasy-jaxrs-3.0.10.Final.jar:] >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.jboss.aerogear.unifiedpush.service.filter.HttpContextFilter.doFilter(HttpContextFilter.java:55) >>> [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] >>> at >>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.jboss.aerogear.unifiedpush.rest.util.VersionFilter.doFilter(VersionFilter.java:65) >>> [unifiedpush-jaxrs-1.1.0.Final.jar:1.1.0.Final] >>> at >>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) >>> [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] >>> at >>> >>> org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) >>> [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >>> [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] >>> at >>> >>> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >>> [keycloak-undertow-adapter-1.3.1.Final.jar:1.3.1.Final] >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) >>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at >>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) >>> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> [rt.jar:1.8.0_45] >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> [rt.jar:1.8.0_45] >>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] >>> Caused by: javax.persistence.PersistenceException: >>> org.hibernate.exception.DataException: could not execute statement >>> at >>> >>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) >>> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) >>> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java: >>> 1683) >>> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1338) >>> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:457) >>> [wildfly-jpa-8.2.0.Final.jar:8.2.0.Final] >>> at sun.reflect.GeneratedMethodAccessor339.invoke(Unknown Source) >>> [:1.8.0_45] >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> [rt.jar:1.8.0_45] >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> [rt.jar:1.8.0_45] >>> at >>> >>> org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:42) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.weldx.persistence.EntityManager$1602193877$Proxy$_$$_Weld$Proxy$.flush(Unknown >>> Source) [hibernate-jpa-2.1-api-1.0.0.Final.jar:] >>> at >>> >>> org.jboss.aerogear.unifiedpush.jpa.dao.impl.JPABaseDao.flushAndClear(JPABaseDao.java:102) >>> [unifiedpush-model-jpa-1.1.0.Final.jar:1.1.0.Final] >>> at >>> >>> org.jboss.aerogear.unifiedpush.service.metrics.PushMessageMetricsService.storeNewRequestFrom(PushMessageMetricsService.java:70) >>> [unifiedpush-service-1.1.0.Final.jar:1.1.0.Final] >>> at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source) >>> [:1.8.0_45] >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> [rt.jar:1.8.0_45] >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> [rt.jar:1.8.0_45] >>> 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.2.0.Final.jar:8.2.0.Final] >>> at >>> >>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) >>> [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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:46) >>> [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] >>> at >>> >>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) >>> [wildfly-weld-8.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.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.2.0.Final.jar:8.2.0.Final] >>> at >>> >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) >>> at >>> >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) >>> [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] >>> ... 174 more >>> Caused by: org.hibernate.exception.DataException: could not execute >>> statement >>> at >>> >>> org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:135) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3124) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3581) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:104) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> >>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1335) >>> [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>> ... 219 more >>> Caused by: org.postgresql.util.PSQLException: ERROR: value too long for >>> type >>> character varying(4500) >>> at >>> >>> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2270) >>> at >>> >>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1998) >>> at >>> >>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) >>> at >>> >>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:570) >>> at >>> >>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:420) >>> at >>> >>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:366) >>> at >>> >>> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) >>> at >>> >>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> ... 229 more >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://aerogear-users.1116366.n5.nabble.com/Aerogear-UPS-1-1-0-Final-max-number-of-aliases-in-push-notification-request-tp321.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 >>> >> >> >> -- >> Sent from Gmail Mobile >> > > > > -- > 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/20151201/edfe6b73/attachment-0001.html From michael at 410labs.com Wed Dec 2 18:24:41 2015 From: michael at 410labs.com (Michael Doo) Date: Wed, 2 Dec 2015 18:24:41 -0500 Subject: [Aerogear-users] OAuth2 session doesn't persist in iOS Message-ID: Hello, When integrating the Aerogear iOS OAuth2 library, I'm adding an account like so: let googleModule = AccountManager.addGoogleAccount(googleConfig) In the current session, I can then make calls like let module = AccountManager.getAccountByName("my_custom_account_name") and retrieve the module to call requestAccess() on and go on with my day. However, if I stop the app or restart the device, the following calls to getAccountByName() returns nil, even when given the same account ID. From the documentation, it's unclear how to persist accounts in the account manager across sessions. Do I need to resurrect the session somehow or reinstantiate it? Or am I missing how AccountManager interacts with the TrustedPersistantOAuth2Session? My goal is to simply be able to authorize multiple Gmail accounts and refresh their access tokens when needed. The AccountManager seemed a good way to do this, but I could be mistaken. Best, Michael Doo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151202/dd7e0fdd/attachment.html From matzew at apache.org Thu Dec 3 03:07:55 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 3 Dec 2015 09:07:55 +0100 Subject: [Aerogear-users] Mobile SSO - web brower+ native iOS In-Reply-To: <1448621360546-312.post@n5.nabble.com> References: <1448621360546-312.post@n5.nabble.com> Message-ID: Hi Jeff, sorry for the late response, but did you checkout keycloak project ? The AeroGear team did do OAuth2 libs for Keycloak, as described here: https://aerogear.org/docs/guides/security/oauth2-guide/ Keycloak itself has also support for web apps (e.g. the UPS is protected by it) HTH, Matthias On Fri, Nov 27, 2015 at 11:49 AM, jeffpower78 wrote: > 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. > _______________________________________________ > 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/20151203/ff0e3b10/attachment.html From corinnekrych at gmail.com Thu Dec 3 03:46:54 2015 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 3 Dec 2015 09:46:54 +0100 Subject: [Aerogear-users] Mobile SSO - web brower+ native iOS In-Reply-To: References: <1448621360546-312.post@n5.nabble.com> Message-ID: Hi Jeff To share OAuth2 tokens between Cordova app and iOS native app on a same mobile, I'd use the Keychain sharing mechanism. I wrote a blog about Keychain sharing between iOS mobile app and its extension [1]. The idea is similar here. I think more work is needed on push plugin to make it more extendable and allow the generation of the required Entitlements.plist file [2]. @Erik can talk more about it and obviously PR are welcome. Last but not least, for security reason, Keychain sharing is allowed only between apps signed by a same organisation. ++ Corinne [1] http://corinnekrych.blogspot.fr/2015/01/sharing-keychain-access-in-share.html [2] http://shaune.com.au/ios-keychain-sharing-data-between-apps/ On 3 December 2015 at 09:07, Matthias Wessendorf wrote: > Hi Jeff, > > sorry for the late response, but did you checkout keycloak project ? The > AeroGear team did do OAuth2 libs for Keycloak, as described here: > https://aerogear.org/docs/guides/security/oauth2-guide/ > > Keycloak itself has also support for web apps (e.g. the UPS is protected > by it) > > HTH, > Matthias > > On Fri, Nov 27, 2015 at 11:49 AM, jeffpower78 > wrote: > >> 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. >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151203/173b47d7/attachment.html From edewit at redhat.com Thu Dec 3 05:29:20 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 3 Dec 2015 11:29:20 +0100 Subject: [Aerogear-users] Mobile SSO - web brower+ native iOS In-Reply-To: References: <1448621360546-312.post@n5.nabble.com> Message-ID: Hi Jeff, Right, so cordova uses the OAuth2 swift code directly so the changes made to the cookbook to allow sharing of the Keychain could also be applied to the cordova plugin. And like Corinne already mentioned it would be nice if this was a feature that one could easily enable. Could you create a feature request for it? On Thu, Dec 3, 2015 at 9:46 AM, Corinne Krych wrote: > Hi Jeff > > To share OAuth2 tokens between Cordova app and iOS native app on a same > mobile, I'd use the Keychain sharing mechanism. I wrote a blog about > Keychain sharing between iOS mobile app and its extension [1]. The idea is > similar here. > > I think more work is needed on push plugin to make it more extendable and > allow the generation of the required Entitlements.plist file [2]. @Erik can > talk more about it and obviously PR are welcome. > > Last but not least, for security reason, Keychain sharing is allowed only > between apps signed by a same organisation. > > ++ > Corinne > [1] > http://corinnekrych.blogspot.fr/2015/01/sharing-keychain-access-in-share.html > [2] http://shaune.com.au/ios-keychain-sharing-data-between-apps/ > > On 3 December 2015 at 09:07, Matthias Wessendorf > wrote: > >> Hi Jeff, >> >> sorry for the late response, but did you checkout keycloak project ? The >> AeroGear team did do OAuth2 libs for Keycloak, as described here: >> https://aerogear.org/docs/guides/security/oauth2-guide/ >> >> Keycloak itself has also support for web apps (e.g. the UPS is protected >> by it) >> >> HTH, >> Matthias >> >> On Fri, Nov 27, 2015 at 11:49 AM, jeffpower78 >> wrote: >> >>> 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. >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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/20151203/d45d0ad0/attachment-0001.html From rob.aerogear at robertwillett.com Thu Dec 3 13:01:02 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Thu, 03 Dec 2015 18:01:02 +0000 Subject: [Aerogear-users] Unclear when to use setContentAvailable() Message-ID: <8BD85719-D586-45EB-8C90-4E0CD02A95F1@robertwillett.com> Hi, We now seem to have something approaching a stable and working UPS configuration. (Famous last words!) Thanks to the Aerogear team for helping resolve the background notifications on Android. As we are tidying up, we noticed (ahem) that we had commented out a few lines in our code. ``` if (event['content-available']) { // Still not clear what to do with this. // push.setContentAvailable(1); } ``` We went back to the Aerogear docs and tried to work out what setContentAvailable really does and what should we do with it. The docs for the function call are a little sparse, so we looked at the source code and we?re still no wiser. Is there a better explanation of when we should call setContentAvailable and with which parameter? Just to set the ball rolling we *think* it could mean that when you receive the content-available = 1 flag on iOS, we do a call to get some data from the server ourselves, if the the results of *our* server call indicate that we have received new data, we set the value to setContentAvailable to 1, if our function call to the server has no data, then we set it to zero and if something failed we set it to 2. So what happens if the value is 0, 1 or 2? if its 2, is a new new call made to something, if its 0 or 1 what happens? Apologies if we?ve missed the point of it, but we?re struggling to understand this. Thanks, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151203/0a087f7a/attachment.html From matzew at apache.org Thu Dec 3 13:23:06 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 3 Dec 2015 19:23:06 +0100 Subject: [Aerogear-users] Unclear when to use setContentAvailable() In-Reply-To: <8BD85719-D586-45EB-8C90-4E0CD02A95F1@robertwillett.com> References: <8BD85719-D586-45EB-8C90-4E0CD02A95F1@robertwillett.com> Message-ID: Hi, it's an iOS feature, that you can use for having the app download something (or check state on your backend), before the alert is being made visible to the end-user: https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Remote_Notifications_iOS_7_and_Greater Also (more interesting, I think) you can use it to send a slient message to the device. E.g. when the app runs (fore/background) the callback is invoked. You can use that to check state on your own backend (a 30 second time window, you have for this), and if needed you could use that to, for instance, issue something local e.g. local notifications (those are better and more handy for several reasons e.g. better control of the badge icon): https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Silent_Remote_Notifications HTH, Matthias On Thu, Dec 3, 2015 at 7:01 PM, Rob Willett wrote: > Hi, > > We now seem to have something approaching a stable and working UPS > configuration. (Famous last words!) Thanks to the Aerogear team for helping > resolve the background notifications on Android. > > As we are tidying up, we noticed (ahem) that we had commented out a few > lines in our code. > > if (event['content-available']) > { > // Still not clear what to do with this. > // push.setContentAvailable(1); > } > > We went back to the Aerogear docs and tried to work out what > setContentAvailable really does and what should we do with it. The docs for > the function call are a little sparse, so we looked at the source code and > we?re still no wiser. > > Is there a better explanation of when we should call setContentAvailable > and with which parameter? > > Just to set the ball rolling we *think* it could mean that when you > receive the content-available = 1 flag on iOS, we do a call to get some > data from the server ourselves, if the the results of *our* server call > indicate that we have received new data, we set the value to > setContentAvailable to 1, if our function call to the server has no data, > then we set it to zero and if something failed we set it to 2. > > So what happens if the value is 0, 1 or 2? if its 2, is a new new call > made to something, if its 0 or 1 what happens? > > Apologies if we?ve missed the point of it, but we?re struggling to > understand this. > > 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/20151203/d5591843/attachment.html From rob.aerogear at robertwillett.com Thu Dec 3 13:40:46 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Thu, 03 Dec 2015 18:40:46 +0000 Subject: [Aerogear-users] Unclear when to use setContentAvailable() In-Reply-To: References: <8BD85719-D586-45EB-8C90-4E0CD02A95F1@robertwillett.com> Message-ID: <281CB0E6-CE84-49D2-BF9F-C3E82D0B03EA@robertwillett.com> Matthia, Thanks for this. Are you referring to content-available flag or the setContentAvailable function? We already send silent notifications out to our Android and Apple devices and the devices handle these correctly. Our logic goes that we send a silent notification to the device via UPS, the device then connects to the server and pulls some data from the server. If our app is in the foreground, we set a tiny alert in the top left of the screen telling the user that something is ready for them, if our app is in the background we set a notification up in the drawer using a local-notification plugin, if the app is not started then the fact the app has not pulled data from the server acts as a flag and we then send down full notifications to the device. The local-notifications and the ?full fat? notifications all work the same way when the user clicks on them. We have all of this is working now without setContentAvailable. Its much as you outlined below. I have two phones on my desk as we speak, an Apple and an Android and we are comparing how the notifications look as we ping different data down to them in different situations. We?re down to design looks now rather than programming :) We?re just trying to work out how setContentAvailable fits into all of this, because we aren?t using it at all! Should we be? Rob On 3 Dec 2015, at 18:23, Matthias Wessendorf wrote: > Hi, > > it's an iOS feature, that you can use for having the app download > something > (or check state on your backend), before the alert is being made > visible to > the end-user: > https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Remote_Notifications_iOS_7_and_Greater > > > Also (more interesting, I think) you can use it to send a slient > message to > the device. E.g. when the app runs (fore/background) the callback is > invoked. You can use that to check state on your own backend (a 30 > second > time window, you have for this), and if needed you could use that to, > for > instance, issue something local e.g. local notifications (those are > better > and more handy for several reasons e.g. better control of the badge > icon): > https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Silent_Remote_Notifications > > HTH, > Matthias > > > On Thu, Dec 3, 2015 at 7:01 PM, Rob Willett > > wrote: > >> Hi, >> >> We now seem to have something approaching a stable and working UPS >> configuration. (Famous last words!) Thanks to the Aerogear team for >> helping >> resolve the background notifications on Android. >> >> As we are tidying up, we noticed (ahem) that we had commented out a >> few >> lines in our code. >> >> if (event['content-available']) >> { >> // Still not clear what to do with this. >> // push.setContentAvailable(1); >> } >> >> We went back to the Aerogear docs and tried to work out what >> setContentAvailable really does and what should we do with it. The >> docs for >> the function call are a little sparse, so we looked at the source >> code and >> we?re still no wiser. >> >> Is there a better explanation of when we should call >> setContentAvailable >> and with which parameter? >> >> Just to set the ball rolling we *think* it could mean that when you >> receive the content-available = 1 flag on iOS, we do a call to get >> some >> data from the server ourselves, if the the results of *our* server >> call >> indicate that we have received new data, we set the value to >> setContentAvailable to 1, if our function call to the server has no >> data, >> then we set it to zero and if something failed we set it to 2. >> >> So what happens if the value is 0, 1 or 2? if its 2, is a new new >> call >> made to something, if its 0 or 1 what happens? >> >> Apologies if we?ve missed the point of it, but we?re struggling >> to >> understand this. >> >> 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 matzew at apache.org Fri Dec 4 02:24:15 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Dec 2015 08:24:15 +0100 Subject: [Aerogear-users] Unclear when to use setContentAvailable() In-Reply-To: <281CB0E6-CE84-49D2-BF9F-C3E82D0B03EA@robertwillett.com> References: <8BD85719-D586-45EB-8C90-4E0CD02A95F1@robertwillett.com> <281CB0E6-CE84-49D2-BF9F-C3E82D0B03EA@robertwillett.com> Message-ID: yeah, I meant the flag. Glad it works for you. I am actually over asked on the client setContentAvailable(). We have the same in our java sender, but that triggers the flag ;) On Thursday, 3 December 2015, Rob Willett wrote: > Matthia, > > Thanks for this. Are you referring to content-available flag or the > setContentAvailable function? > > We already send silent notifications out to our Android and Apple > devices and the devices handle these correctly. > > Our logic goes that we send a silent notification to the device via UPS, > the device then connects to the server and pulls some data from the > server. If our app is in the foreground, we set a tiny alert in the top > left of the screen telling the user that something is ready for them, if > our app is in the background we set a notification up in the drawer > using a local-notification plugin, if the app is not started then the > fact the app has not pulled data from the server acts as a flag and we > then send down full notifications to the device. The local-notifications > and the ?full fat? notifications all work the same way when the user > clicks on them. > > We have all of this is working now without setContentAvailable. Its much > as you outlined below. I have two phones on my desk as we speak, an > Apple and an Android and we are comparing how the notifications look as > we ping different data down to them in different situations. We?re > down to design looks now rather than programming :) > > We?re just trying to work out how setContentAvailable fits into all of > this, because we aren?t using it at all! Should we be? > > Rob > > On 3 Dec 2015, at 18:23, Matthias Wessendorf wrote: > > > Hi, > > > > it's an iOS feature, that you can use for having the app download > > something > > (or check state on your backend), before the alert is being made > > visible to > > the end-user: > > > https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Remote_Notifications_iOS_7_and_Greater > > > > > > Also (more interesting, I think) you can use it to send a slient > > message to > > the device. E.g. when the app runs (fore/background) the callback is > > invoked. You can use that to check state on your own backend (a 30 > > second > > time window, you have for this), and if needed you could use that to, > > for > > instance, issue something local e.g. local notifications (those are > > better > > and more handy for several reasons e.g. better control of the badge > > icon): > > > https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Silent_Remote_Notifications > > > > HTH, > > Matthias > > > > > > On Thu, Dec 3, 2015 at 7:01 PM, Rob Willett > > > > > wrote: > > > >> Hi, > >> > >> We now seem to have something approaching a stable and working UPS > >> configuration. (Famous last words!) Thanks to the Aerogear team for > >> helping > >> resolve the background notifications on Android. > >> > >> As we are tidying up, we noticed (ahem) that we had commented out a > >> few > >> lines in our code. > >> > >> if (event['content-available']) > >> { > >> // Still not clear what to do with this. > >> // push.setContentAvailable(1); > >> } > >> > >> We went back to the Aerogear docs and tried to work out what > >> setContentAvailable really does and what should we do with it. The > >> docs for > >> the function call are a little sparse, so we looked at the source > >> code and > >> we?re still no wiser. > >> > >> Is there a better explanation of when we should call > >> setContentAvailable > >> and with which parameter? > >> > >> Just to set the ball rolling we *think* it could mean that when you > >> receive the content-available = 1 flag on iOS, we do a call to get > >> some > >> data from the server ourselves, if the the results of *our* server > >> call > >> indicate that we have received new data, we set the value to > >> setContentAvailable to 1, if our function call to the server has no > >> data, > >> then we set it to zero and if something failed we set it to 2. > >> > >> So what happens if the value is 0, 1 or 2? if its 2, is a new new > >> call > >> made to something, if its 0 or 1 what happens? > >> > >> Apologies if we?ve missed the point of it, but we?re struggling > >> to > >> understand this. > >> > >> 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 > > _______________________________________________ > Aerogear-users mailing list > Aerogear-users at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151204/37d6763a/attachment-0001.html From edewit at redhat.com Fri Dec 4 03:03:58 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 4 Dec 2015 09:03:58 +0100 Subject: [Aerogear-users] Unclear when to use setContentAvailable() In-Reply-To: References: <8BD85719-D586-45EB-8C90-4E0CD02A95F1@robertwillett.com> <281CB0E6-CE84-49D2-BF9F-C3E82D0B03EA@robertwillett.com> Message-ID: Hi Rob, I think we talked about this before, but the silent (content-available) notifications are scheduled by iOS, e.g. there are some heuristic involved. And they are coupled to background content fetching, so when your app receives a 'content-available' silent notification it has 30 seconds to act and afterwards it has to inform the os of the result. That is what this function is for, then the os can use this information along with how often it's used to schedule the next invocation. I agree we have a bit sparse documentation [1]. And also what apple writes is a bit sparse [2]. But you must set this result otherwise your app might not get invoked anymore. In the js api there is an enum with possible values that you can use [3] [1] https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification [2] https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html [3] https://github.com/aerogear/aerogear-cordova-push/blob/master/www/aerogear-push.js#L26-L36 On Fri, Dec 4, 2015 at 8:24 AM, Matthias Wessendorf wrote: > yeah, I meant the flag. Glad it works for you. > > I am actually over asked on the client setContentAvailable(). > > > We have the same in our java sender, but that triggers the flag ;) > > > On Thursday, 3 December 2015, Rob Willett > wrote: > >> Matthia, >> >> Thanks for this. Are you referring to content-available flag or the >> setContentAvailable function? >> >> We already send silent notifications out to our Android and Apple >> devices and the devices handle these correctly. >> >> Our logic goes that we send a silent notification to the device via UPS, >> the device then connects to the server and pulls some data from the >> server. If our app is in the foreground, we set a tiny alert in the top >> left of the screen telling the user that something is ready for them, if >> our app is in the background we set a notification up in the drawer >> using a local-notification plugin, if the app is not started then the >> fact the app has not pulled data from the server acts as a flag and we >> then send down full notifications to the device. The local-notifications >> and the ?full fat? notifications all work the same way when the user >> clicks on them. >> >> We have all of this is working now without setContentAvailable. Its much >> as you outlined below. I have two phones on my desk as we speak, an >> Apple and an Android and we are comparing how the notifications look as >> we ping different data down to them in different situations. We?re >> down to design looks now rather than programming :) >> >> We?re just trying to work out how setContentAvailable fits into all of >> this, because we aren?t using it at all! Should we be? >> >> Rob >> >> On 3 Dec 2015, at 18:23, Matthias Wessendorf wrote: >> >> > Hi, >> > >> > it's an iOS feature, that you can use for having the app download >> > something >> > (or check state on your backend), before the alert is being made >> > visible to >> > the end-user: >> > >> https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Remote_Notifications_iOS_7_and_Greater >> > >> > >> > Also (more interesting, I think) you can use it to send a slient >> > message to >> > the device. E.g. when the app runs (fore/background) the callback is >> > invoked. You can use that to check state on your own backend (a 30 >> > second >> > time window, you have for this), and if needed you could use that to, >> > for >> > instance, issue something local e.g. local notifications (those are >> > better >> > and more handy for several reasons e.g. better control of the badge >> > icon): >> > >> https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Silent_Remote_Notifications >> > >> > HTH, >> > Matthias >> > >> > >> > On Thu, Dec 3, 2015 at 7:01 PM, Rob Willett >> > >> > wrote: >> > >> >> Hi, >> >> >> >> We now seem to have something approaching a stable and working UPS >> >> configuration. (Famous last words!) Thanks to the Aerogear team for >> >> helping >> >> resolve the background notifications on Android. >> >> >> >> As we are tidying up, we noticed (ahem) that we had commented out a >> >> few >> >> lines in our code. >> >> >> >> if (event['content-available']) >> >> { >> >> // Still not clear what to do with this. >> >> // push.setContentAvailable(1); >> >> } >> >> >> >> We went back to the Aerogear docs and tried to work out what >> >> setContentAvailable really does and what should we do with it. The >> >> docs for >> >> the function call are a little sparse, so we looked at the source >> >> code and >> >> we?re still no wiser. >> >> >> >> Is there a better explanation of when we should call >> >> setContentAvailable >> >> and with which parameter? >> >> >> >> Just to set the ball rolling we *think* it could mean that when you >> >> receive the content-available = 1 flag on iOS, we do a call to get >> >> some >> >> data from the server ourselves, if the the results of *our* server >> >> call >> >> indicate that we have received new data, we set the value to >> >> setContentAvailable to 1, if our function call to the server has no >> >> data, >> >> then we set it to zero and if something failed we set it to 2. >> >> >> >> So what happens if the value is 0, 1 or 2? if its 2, is a new new >> >> call >> >> made to something, if its 0 or 1 what happens? >> >> >> >> Apologies if we?ve missed the point of it, but we?re struggling >> >> to >> >> understand this. >> >> >> >> 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 >> >> _______________________________________________ >> Aerogear-users mailing list >> Aerogear-users at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-users >> > > > -- > Sent from Gmail Mobile > > _______________________________________________ > 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/20151204/4e75efc9/attachment.html From rob.aerogear at robertwillett.com Fri Dec 4 03:57:18 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Fri, 04 Dec 2015 08:57:18 +0000 Subject: [Aerogear-users] Unclear when to use setContentAvailable() In-Reply-To: References: <8BD85719-D586-45EB-8C90-4E0CD02A95F1@robertwillett.com> <281CB0E6-CE84-49D2-BF9F-C3E82D0B03EA@robertwillett.com> Message-ID: Erik, Matthias, Thanks for the comments and help. I *think* we understand now what to do with setContentAvailable. 1. We get the silent notification telling the app that data is available,. This is through the content-available flag - Working in our app. 2. We use the silent notification to go get some more data (typically in our case around 4-5KB) through an XHR call - Working in our app. 3 When we have got the data from our server and we have processed the data, we call push.setContentAvailable with either NewData, NoData or Failed as a parameter. This tells iOS that our background execution is all down with and iOS can do whatever else it needs to - We have just added this logic (well a single line) to our app at the end of our functions, GetNotificationsFromServerSuccess() and GetNotificationsFromServerFailure(). We have imaginative names on our project :) We have read the docs you supplied and quite a lot of others, including other 3rd party push providers to try and understand it. Since everything was working at our end without push.setContentAvailable() we were puzzled as to its importance. So all the push.setContentAvailable does is tell IOS we are finished with background execution, and the parameter is the result of that background execution? Its a tidy up function for iOS background execution. Thanks, Rob On 4 Dec 2015, at 8:03, Erik Jan de Wit wrote: > Hi Rob, > > I think we talked about this before, but the silent > (content-available) > notifications are scheduled by iOS, e.g. there are some heuristic > involved. > And they are coupled to background content fetching, so when your app > receives a 'content-available' silent notification it has 30 seconds > to act > and afterwards it has to inform the os of the result. That is what > this > function is for, then the os can use this information along with how > often > it's used to schedule the next invocation. I agree we have a bit > sparse > documentation [1]. And also what apple writes is a bit sparse [2]. But > you > must set this result otherwise your app might not get invoked anymore. > In > the js api there is an enum with possible values that you can use [3] > > [1] > https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification > [2] > https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html > [3] > https://github.com/aerogear/aerogear-cordova-push/blob/master/www/aerogear-push.js#L26-L36 > > On Fri, Dec 4, 2015 at 8:24 AM, Matthias Wessendorf > > wrote: > >> yeah, I meant the flag. Glad it works for you. >> >> I am actually over asked on the client setContentAvailable(). >> >> >> We have the same in our java sender, but that triggers the flag ;) >> >> >> On Thursday, 3 December 2015, Rob Willett >> >> wrote: >> >>> Matthia, >>> >>> Thanks for this. Are you referring to content-available flag or the >>> setContentAvailable function? >>> >>> We already send silent notifications out to our Android and Apple >>> devices and the devices handle these correctly. >>> >>> Our logic goes that we send a silent notification to the device via >>> UPS, >>> the device then connects to the server and pulls some data from the >>> server. If our app is in the foreground, we set a tiny alert in the >>> top >>> left of the screen telling the user that something is ready for >>> them, if >>> our app is in the background we set a notification up in the drawer >>> using a local-notification plugin, if the app is not started then >>> the >>> fact the app has not pulled data from the server acts as a flag and >>> we >>> then send down full notifications to the device. The >>> local-notifications >>> and the ?full fat? notifications all work the same way when the >>> user >>> clicks on them. >>> >>> We have all of this is working now without setContentAvailable. Its >>> much >>> as you outlined below. I have two phones on my desk as we speak, an >>> Apple and an Android and we are comparing how the notifications look >>> as >>> we ping different data down to them in different situations. We?re >>> down to design looks now rather than programming :) >>> >>> We?re just trying to work out how setContentAvailable fits into >>> all of >>> this, because we aren?t using it at all! Should we be? >>> >>> Rob >>> >>> On 3 Dec 2015, at 18:23, Matthias Wessendorf wrote: >>> >>>> Hi, >>>> >>>> it's an iOS feature, that you can use for having the app download >>>> something >>>> (or check state on your backend), before the alert is being made >>>> visible to >>>> the end-user: >>>> >>> https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Remote_Notifications_iOS_7_and_Greater >>>> >>>> >>>> Also (more interesting, I think) you can use it to send a slient >>>> message to >>>> the device. E.g. when the app runs (fore/background) the callback >>>> is >>>> invoked. You can use that to check state on your own backend (a 30 >>>> second >>>> time window, you have for this), and if needed you could use that >>>> to, >>>> for >>>> instance, issue something local e.g. local notifications (those are >>>> better >>>> and more handy for several reasons e.g. better control of the badge >>>> icon): >>>> >>> https://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/#Silent_Remote_Notifications >>>> >>>> HTH, >>>> Matthias >>>> >>>> >>>> On Thu, Dec 3, 2015 at 7:01 PM, Rob Willett >>>> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> We now seem to have something approaching a stable and working UPS >>>>> configuration. (Famous last words!) Thanks to the Aerogear team >>>>> for >>>>> helping >>>>> resolve the background notifications on Android. >>>>> >>>>> As we are tidying up, we noticed (ahem) that we had commented out >>>>> a >>>>> few >>>>> lines in our code. >>>>> >>>>> if (event['content-available']) >>>>> { >>>>> // Still not clear what to do with this. >>>>> // push.setContentAvailable(1); >>>>> } >>>>> >>>>> We went back to the Aerogear docs and tried to work out what >>>>> setContentAvailable really does and what should we do with it. The >>>>> docs for >>>>> the function call are a little sparse, so we looked at the source >>>>> code and >>>>> we?re still no wiser. >>>>> >>>>> Is there a better explanation of when we should call >>>>> setContentAvailable >>>>> and with which parameter? >>>>> >>>>> Just to set the ball rolling we *think* it could mean that when >>>>> you >>>>> receive the content-available = 1 flag on iOS, we do a call to get >>>>> some >>>>> data from the server ourselves, if the the results of *our* server >>>>> call >>>>> indicate that we have received new data, we set the value to >>>>> setContentAvailable to 1, if our function call to the server has >>>>> no >>>>> data, >>>>> then we set it to zero and if something failed we set it to 2. >>>>> >>>>> So what happens if the value is 0, 1 or 2? if its 2, is a new new >>>>> call >>>>> made to something, if its 0 or 1 what happens? >>>>> >>>>> Apologies if we?ve missed the point of it, but we?re >>>>> struggling >>>>> to >>>>> understand this. >>>>> >>>>> 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 >>> >>> _______________________________________________ >>> Aerogear-users mailing list >>> Aerogear-users at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-users >>> >> >> >> -- >> Sent from Gmail Mobile >> >> _______________________________________________ >> 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 From edewit at redhat.com Fri Dec 4 04:31:28 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 4 Dec 2015 10:31:28 +0100 Subject: [Aerogear-users] Cordova push 2.0.4 release Message-ID: Hi all, There have been some cool new feature and some bug fixes added to the cordova push plugin that we would like to release. As as usual I've created a release branch to test called 2.0.4-release. Included in this release are the following: PTKeySummary [image: Major][image: Feature Request]AGCORDOVA-111 Add update alias and categories for windows [image: Major][image: Feature Request]AGCORDOVA-113 Stack messages on Android [image: Major][image: Bug]AGCORDOVA-120 NullReferenceException when delivering message to WP8 app on foreground [image: Major][image: Bug]AGCORDOVA-124 Cordova Push Plugin crashes Android app in background when a notification with an empty alert string is sent [image: Major][image: Bug]AGCORDOVA-125 Success callback only fired once. [image: Major][image: Feature Request]AGCORDOVA-126 Add ability to include alias and category on register [image: Major][image: Bug]AGCORDOVA-128 Windows 10 runtime error -- Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151204/8e723337/attachment.html From matzew at apache.org Fri Dec 4 04:34:47 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Dec 2015 10:34:47 +0100 Subject: [Aerogear-users] Cordova push 2.0.4 release In-Reply-To: References: Message-ID: yay! On Fri, Dec 4, 2015 at 10:31 AM, Erik Jan de Wit wrote: > Hi all, > > There have been some cool new feature and some bug fixes added to the > cordova push plugin that we would like to release. As as usual I've created > a release branch to test called 2.0.4-release. Included in this release are > the following: > > PTKeySummary > > > [image: Major][image: Feature Request]AGCORDOVA-111 > Add update alias and > categories for windows > > [image: Major][image: Feature Request]AGCORDOVA-113 > Stack messages on Android > > > [image: Major][image: Bug]AGCORDOVA-120 > NullReferenceException > when delivering message to WP8 app on foreground > > > [image: Major][image: Bug]AGCORDOVA-124 > Cordova Push Plugin > crashes Android app in background when a notification with an empty alert > string is sent > > [image: Major][image: Bug]AGCORDOVA-125 > Success callback only > fired once. > > [image: Major][image: Feature Request]AGCORDOVA-126 > Add ability to include > alias and category on register > > > [image: Major][image: Bug]AGCORDOVA-128 > Windows 10 runtime error > > > -- > Cheers, > Erik Jan > > _______________________________________________ > Aerogear-users mailing list > Aerogear-users at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151204/1f193411/attachment-0001.html From rob.aerogear at robertwillett.com Fri Dec 4 04:37:50 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Fri, 04 Dec 2015 09:37:50 +0000 Subject: [Aerogear-users] Cordova push 2.0.4 release In-Reply-To: References: Message-ID: <99F2CF20-9EB7-45F6-913E-8E7AE41E3381@robertwillett.com> Erik, Already using two of these, stacked messages on Android and the fix for empty alerts strings. I would argue that Windows 10 runtime error is enough of an explanation in itself and no further explanation is necessary but I won?t :) Thanks again for the fast turnaround Rob On 4 Dec 2015, at 9:31, Erik Jan de Wit wrote: > Hi all, > > There have been some cool new feature and some bug fixes added to the > cordova push plugin that we would like to release. As as usual I've > created > a release branch to test called 2.0.4-release. Included in this > release are > the following: > > PTKeySummary > > > [image: Major][image: Feature Request]AGCORDOVA-111 > Add update alias and > categories for windows > > [image: Major][image: Feature Request]AGCORDOVA-113 > Stack messages on > Android > > > [image: Major][image: Bug]AGCORDOVA-120 > NullReferenceException > when > delivering message to WP8 app on foreground > > > [image: Major][image: Bug]AGCORDOVA-124 > Cordova Push Plugin > crashes > Android app in background when a notification with an empty alert > string is > sent > > [image: Major][image: Bug]AGCORDOVA-125 > Success callback only > fired > once. > > [image: Major][image: Feature Request]AGCORDOVA-126 > Add ability to include > alias > and category on register > > > [image: Major][image: Bug]AGCORDOVA-128 > Windows 10 runtime > error > > > -- > Cheers, > Erik Jan > _______________________________________________ > Aerogear-users mailing list > Aerogear-users at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users From edewit at redhat.com Fri Dec 4 04:47:50 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 4 Dec 2015 10:47:50 +0100 Subject: [Aerogear-users] Cordova push 2.0.4 release In-Reply-To: <99F2CF20-9EB7-45F6-913E-8E7AE41E3381@robertwillett.com> References: <99F2CF20-9EB7-45F6-913E-8E7AE41E3381@robertwillett.com> Message-ID: Hi Rob, Yeah you can already use these features when you add the plugin via the git repository url, but not everybody uses it like this. One can also install the plugin using the plugin id, releases are then downloaded from npm. I'm confident that things work because you have tested some of these features already, thanks for that. More information on the windows bug, can be found in the issue details. The problem was that the proxy is looking up the plugin javascript with the old id, the one from before moving to npm. On Fri, Dec 4, 2015 at 10:37 AM, Rob Willett wrote: > Erik, > > Already using two of these, stacked messages on Android and the fix for > empty alerts strings. > > I would argue that Windows 10 runtime error is enough of an explanation > in itself and no further explanation is necessary but I won?t :) > > Thanks again for the fast turnaround > > Rob > > On 4 Dec 2015, at 9:31, Erik Jan de Wit wrote: > > > Hi all, > > > > There have been some cool new feature and some bug fixes added to the > > cordova push plugin that we would like to release. As as usual I've > > created > > a release branch to test called 2.0.4-release. Included in this > > release are > > the following: > > > > PTKeySummary > > > > > > [image: Major][image: Feature Request]AGCORDOVA-111 > > Add update alias and > > categories for windows > > > > [image: Major][image: Feature Request]AGCORDOVA-113 > > Stack messages on > > Android > > > > > > [image: Major][image: Bug]AGCORDOVA-120 > > NullReferenceException > > when > > delivering message to WP8 app on foreground > > > > > > [image: Major][image: Bug]AGCORDOVA-124 > > Cordova Push Plugin > > crashes > > Android app in background when a notification with an empty alert > > string is > > sent > > > > [image: Major][image: Bug]AGCORDOVA-125 > > Success callback only > > fired > > once. > > > > [image: Major][image: Feature Request]AGCORDOVA-126 > > Add ability to include > > alias > > and category on register > > > > > > [image: Major][image: Bug]AGCORDOVA-128 > > Windows 10 runtime > > error > > > > > > -- > > 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 > -- Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151204/54fb621c/attachment.html From michael at 410labs.com Fri Dec 4 17:18:02 2015 From: michael at 410labs.com (Michael Doo) Date: Fri, 4 Dec 2015 17:18:02 -0500 Subject: [Aerogear-users] iOS OAuth2 redirect URIs Message-ID: Hello, I've managed to integrate the Aerogear iOS OAuth2 library pretty well into my app for Google accounts. However, for Outlook, their OAuth2 API only allow two redirect URIs: urn:ietf:wg:oauth:2.0:oob and HTTPS schemes, e.g., https://login.live.com/oauth20_desktop.srf, to which the authorization code will be attached. The important bit here is that they do not allow customization of the redirect URI to be something like '\(bundleString)://oauth2Callback' or 'fb\(clientId)://authorize/', which the OAuth2 library seems to need. The documentation doesn't seem to clearly state how this should or could be addressed. Since not every OAuth2 provider has allowed iOS bundle names as valid redirect URIs, it seems to me there should be a way to handle this. Best, Michael Doo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151204/35c412d0/attachment.html From matzew at apache.org Mon Dec 7 10:32:08 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Dec 2015 16:32:08 +0100 Subject: [Aerogear-users] iOS OAuth2 redirect URIs In-Reply-To: References: Message-ID: Hi, mind filing a JIRA ticket, if there is a bit of missing functionality for a more generic usage. I think we should not end up adding an Outlook speciifc class, but I agree that it might be handy to have a bit of more flexibility here On Fri, Dec 4, 2015 at 11:18 PM, Michael Doo wrote: > Hello, > > I've managed to integrate the Aerogear iOS OAuth2 library pretty well into > my app for Google accounts. However, for Outlook, their OAuth2 API only > allow two redirect URIs: urn:ietf:wg:oauth:2.0:oob and HTTPS schemes, e.g., > https://login.live.com/oauth20_desktop.srf, to which the authorization > code will be attached. The important bit here is that they do not allow > customization of the redirect URI to be something like > '\(bundleString)://oauth2Callback' or 'fb\(clientId)://authorize/', which > the OAuth2 library seems to need. > > The documentation doesn't seem to clearly state how this should or could > be addressed. Since not every OAuth2 provider has allowed iOS bundle names > as valid redirect URIs, it seems to me there should be a way to handle this. > > Best, > Michael Doo > > _______________________________________________ > 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/20151207/0ab59195/attachment.html From matzew at apache.org Mon Dec 7 10:32:32 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Dec 2015 16:32:32 +0100 Subject: [Aerogear-users] iOS OAuth2 redirect URIs In-Reply-To: References: Message-ID: for got the JIRA link: http://jira.jboss.org/browse/AGIOS On Mon, Dec 7, 2015 at 4:32 PM, Matthias Wessendorf wrote: > Hi, > > mind filing a JIRA ticket, if there is a bit of missing functionality for > a more generic usage. > > I think we should not end up adding an Outlook speciifc class, but I agree > that it might be handy to have a bit of more flexibility here > > On Fri, Dec 4, 2015 at 11:18 PM, Michael Doo wrote: > >> Hello, >> >> I've managed to integrate the Aerogear iOS OAuth2 library pretty well >> into my app for Google accounts. However, for Outlook, their OAuth2 API >> only allow two redirect URIs: urn:ietf:wg:oauth:2.0:oob and HTTPS schemes, >> e.g., https://login.live.com/oauth20_desktop.srf, to which the >> authorization code will be attached. The important bit here is that they do >> not allow customization of the redirect URI to be something like >> '\(bundleString)://oauth2Callback' or 'fb\(clientId)://authorize/', which >> the OAuth2 library seems to need. >> >> The documentation doesn't seem to clearly state how this should or could >> be addressed. Since not every OAuth2 provider has allowed iOS bundle names >> as valid redirect URIs, it seems to me there should be a way to handle this. >> >> Best, >> Michael Doo >> >> _______________________________________________ >> 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/20151207/0f1be1e5/attachment-0001.html From edewit at redhat.com Wed Dec 9 03:29:24 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 9 Dec 2015 09:29:24 +0100 Subject: [Aerogear-users] Cordova push 2.0.4 released Message-ID: Hi all, I've pushed the release button, again what has changed this release: Bug AGCORDOVA-120 - NullReferenceException when delivering message to WP8 app on foreground AGCORDOVA-124 - Cordova Push Plugin crashes Android app in background when a notification with an empty alert string is sent AGCORDOVA-125 - Success callback only fired once. AGCORDOVA-128 - Windows 10 runtime error Feature Request AGCORDOVA-111 - Add update alias and categories for windows AGCORDOVA-113 - Stack messages on Android AGCORDOVA-126 - Add ability to include alias and category on register *Happy coding!* -- Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151209/55e78154/attachment.html From alexandre.balleste at udl.cat Thu Dec 10 08:23:22 2015 From: alexandre.balleste at udl.cat (=?UTF-8?B?QWxleCBCYWxsZXN0w6k=?=) Date: Thu, 10 Dec 2015 14:23:22 +0100 Subject: [Aerogear-users] Duplicated notifications Message-ID: <56697CCA.3090006@udl.cat> Hi, recently I've updated to 2.0.4 cordova plugin and I noticed that lot of times notifications are not displayed. Others the notifications are displayed multiple times in the bar but it was only sent once, and others times are shown with some older that I've already received. Any suggestion to find what's happening? Things already detected: If APP is closed I've see the notification with "1" number. If opened I see it with an "8" . Screenshots: http://ibin.co/2PTCBCRewjEx http://ibin.co/2PTCPYtIqiJy Following the stacktrace of the last message sent: http://pastebin.com/FtFr6fbc Thanks Alex. -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151210/dbe6ff19/attachment.html From aamagdi at ejada.com Thu Dec 10 09:57:56 2015 From: aamagdi at ejada.com (aamagdi) Date: Thu, 10 Dec 2015 07:57:56 -0700 (MST) Subject: [Aerogear-users] Arabic Characters in Notification Message-ID: <1449759476978-344.post@n5.nabble.com> Hi Whenever I try to send a notification to my application while this notification contains Arabic characters. it appear as as series of question marks like ?????, this occur only in Android but it displayed correctly in iOS and admin UI activity log. Thanks Abdalla Soliman -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344.html Sent from the aerogear-users mailing list archive at Nabble.com. From lholmqui at redhat.com Thu Dec 10 09:59:28 2015 From: lholmqui at redhat.com (Luke Holmquist) Date: Thu, 10 Dec 2015 09:59:28 -0500 Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: <1449759476978-344.post@n5.nabble.com> References: <1449759476978-344.post@n5.nabble.com> Message-ID: hello, what version of Android are you using? On Thu, Dec 10, 2015 at 9:57 AM, aamagdi wrote: > Hi > > Whenever I try to send a notification to my application while this > notification contains Arabic characters. > it appear as as series of question marks like ?????, this occur only in > Android but it displayed correctly in iOS and admin UI activity log. > > Thanks > Abdalla Soliman > > > > -- > View this message in context: > http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151210/85364c18/attachment.html From aamagdi at ejada.com Thu Dec 10 10:02:59 2015 From: aamagdi at ejada.com (aamagdi) Date: Thu, 10 Dec 2015 08:02:59 -0700 (MST) Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: References: <1449759476978-344.post@n5.nabble.com> Message-ID: <1449759779859-346.post@n5.nabble.com> My test was on Android 4.3 on samasung galalxy s3 -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344p346.html Sent from the aerogear-users mailing list archive at Nabble.com. From matzew at apache.org Thu Dec 10 10:20:42 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Dec 2015 16:20:42 +0100 Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: <1449759779859-346.post@n5.nabble.com> References: <1449759476978-344.post@n5.nabble.com> <1449759779859-346.post@n5.nabble.com> Message-ID: what's your database, and encoding ? On Thu, Dec 10, 2015 at 4:02 PM, aamagdi wrote: > My test was on Android 4.3 on samasung galalxy s3 > > > > -- > View this message in context: > http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344p346.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/20151210/a9a293cb/attachment.html From aamagdi at ejada.com Thu Dec 10 10:43:12 2015 From: aamagdi at ejada.com (aamagdi) Date: Thu, 10 Dec 2015 08:43:12 -0700 (MST) Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: References: <1449759476978-344.post@n5.nabble.com> <1449759779859-346.post@n5.nabble.com> Message-ID: <1449762192606-348.post@n5.nabble.com> I deployed the unified push server following the guide on the website with the default configuration on mysql database and wildfly application server Also my application using aerogear cordova plugin for iOS and Android -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344p348.html Sent from the aerogear-users mailing list archive at Nabble.com. From matzew at apache.org Thu Dec 10 11:01:01 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Dec 2015 17:01:01 +0100 Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: <1449762192606-348.post@n5.nabble.com> References: <1449759476978-344.post@n5.nabble.com> <1449759779859-346.post@n5.nabble.com> <1449762192606-348.post@n5.nabble.com> Message-ID: ok, does the arabic work on iOS ? I know that some other multi-byte characters work (e.g. emojs and German umlauts) On Thu, Dec 10, 2015 at 4:43 PM, aamagdi wrote: > I deployed the unified push server following the guide on the website with > the default configuration on mysql database and wildfly application server > Also my application using aerogear cordova plugin for iOS and Android > > > > -- > View this message in context: > http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344p348.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/20151210/d544be65/attachment-0001.html From scm.blanc at gmail.com Thu Dec 10 11:01:59 2015 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 10 Dec 2015 17:01:59 +0100 Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: <1449762192606-348.post@n5.nabble.com> References: <1449759476978-344.post@n5.nabble.com> <1449759779859-346.post@n5.nabble.com> <1449762192606-348.post@n5.nabble.com> Message-ID: Just FYI I just tried with UPS 1.1 Deployed on OpenShift (so with MySql) and my Android 5.0 , translated "hello world" with google to ????? ??????? :) , it works on my side, both in the notification tray and in the application itself. On Thu, Dec 10, 2015 at 4:43 PM, aamagdi wrote: > I deployed the unified push server following the guide on the website with > the default configuration on mysql database and wildfly application server > Also my application using aerogear cordova plugin for iOS and Android > > > > -- > View this message in context: > http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344p348.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151210/99b45f7f/attachment.html From aamagdi at ejada.com Thu Dec 10 11:03:06 2015 From: aamagdi at ejada.com (aamagdi) Date: Thu, 10 Dec 2015 09:03:06 -0700 (MST) Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: References: <1449759476978-344.post@n5.nabble.com> <1449759779859-346.post@n5.nabble.com> <1449762192606-348.post@n5.nabble.com> Message-ID: <1449763386732-351.post@n5.nabble.com> Yes, Arabic work fine in iOS and the notification appear correctly -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344p351.html Sent from the aerogear-users mailing list archive at Nabble.com. From matzew at apache.org Thu Dec 10 11:05:25 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Dec 2015 17:05:25 +0100 Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: <1449763386732-351.post@n5.nabble.com> References: <1449759476978-344.post@n5.nabble.com> <1449759779859-346.post@n5.nabble.com> <1449762192606-348.post@n5.nabble.com> <1449763386732-351.post@n5.nabble.com> Message-ID: Damn, Android! :) Ok, not sure, how to configure that, in the android app - e.g. encoding. I recall our HelloWorld demo supports emoji, mind trying this app real quick for your use-case? https://github.com/jboss-mobile/unified-push-helloworld/tree/master/android On Thu, Dec 10, 2015 at 5:03 PM, aamagdi wrote: > Yes, Arabic work fine in iOS and the notification appear correctly > > > > -- > View this message in context: > http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344p351.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/20151210/cc2d5596/attachment.html From aamagdi at ejada.com Thu Dec 10 12:11:15 2015 From: aamagdi at ejada.com (aamagdi) Date: Thu, 10 Dec 2015 10:11:15 -0700 (MST) Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: References: <1449759476978-344.post@n5.nabble.com> <1449759779859-346.post@n5.nabble.com> <1449762192606-348.post@n5.nabble.com> <1449763386732-351.post@n5.nabble.com> Message-ID: <1449767475847-353.post@n5.nabble.com> I tried unified-push-helloworld android app but I got the same issue as per the below shots, also I tried it on another android device *Samsung galaxy tab s - Android 5.0.2* and still the same issue exist -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344p353.html Sent from the aerogear-users mailing list archive at Nabble.com. From Michael.Fischelmayer at apa.at Fri Dec 11 03:26:29 2015 From: Michael.Fischelmayer at apa.at (Fischelmayer Michael) Date: Fri, 11 Dec 2015 08:26:29 +0000 Subject: [Aerogear-users] Health Info Endpoint Message-ID: <786E2E9282CC0147A0F31612AA2B648F0494573B@apawinmbx01.lan.apa.at> Hello, How is the Health Status Enpoint protected? https://SERVER:PORT/CONTEXT/rest/sys/info/health/ I get an 401 but I can't find the protection method in the rest docu. https://aerogear.org/docs/specs/aerogear-unifiedpush-rest/index.html#-2006359689 Thanks and Regards Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151211/6a8eb209/attachment.html From scm.blanc at gmail.com Fri Dec 11 03:35:29 2015 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 11 Dec 2015 09:35:29 +0100 Subject: [Aerogear-users] Health Info Endpoint In-Reply-To: <786E2E9282CC0147A0F31612AA2B648F0494573B@apawinmbx01.lan.apa.at> References: <786E2E9282CC0147A0F31612AA2B648F0494573B@apawinmbx01.lan.apa.at> Message-ID: Hi Michael, The health endpoint is protected by Keycloak, you can see here the different patterns on how the endpoints are protected https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-wildfly/src/main/webapp/WEB-INF/web.xml Here also a sample on how you could call this endpoint from a third party app/lib: https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/node.js/directgranttest.js Here we create a Push Application but you could adapt it easily to ping the health endpoint. Sebi On Fri, Dec 11, 2015 at 9:26 AM, Fischelmayer Michael < Michael.Fischelmayer at apa.at> wrote: > Hello, > > > > How is the Health Status Enpoint protected? > > https://SERVER:PORT/CONTEXT/rest/sys/info/health/ > > > > I get an 401 but I can?t find the protection method in the rest docu. > > > https://aerogear.org/docs/specs/aerogear-unifiedpush-rest/index.html#-2006359689 > > > > Thanks and Regards > Michael > > _______________________________________________ > 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/20151211/d39aabf8/attachment-0001.html From matzew at apache.org Fri Dec 11 03:43:06 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 11 Dec 2015 09:43:06 +0100 Subject: [Aerogear-users] Health Info Endpoint In-Reply-To: References: <786E2E9282CC0147A0F31612AA2B648F0494573B@apawinmbx01.lan.apa.at> Message-ID: On Fri, Dec 11, 2015 at 9:35 AM, Sebastien Blanc wrote: > Hi Michael, > > The health endpoint is protected by Keycloak, you can see here the > different patterns on how the endpoints are protected > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-wildfly/src/main/webapp/WEB-INF/web.xml > > I'd not change that. > Here also a sample on how you could call this endpoint from a third party > app/lib: > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/node.js/directgranttest.js > > Here we create a Push Application but you could adapt it easily to ping > the health endpoint. > the readme contains some hints on the required Keycloak update for that Actually, isnt it lame the UI does not show the info - somewhere ? > > Sebi > > > On Fri, Dec 11, 2015 at 9:26 AM, Fischelmayer Michael < > Michael.Fischelmayer at apa.at> wrote: > >> Hello, >> >> >> >> How is the Health Status Enpoint protected? >> >> https://SERVER:PORT/CONTEXT/rest/sys/info/health/ >> >> >> >> I get an 401 but I can?t find the protection method in the rest docu. >> >> >> https://aerogear.org/docs/specs/aerogear-unifiedpush-rest/index.html#-2006359689 >> >> >> >> Thanks and Regards >> Michael >> >> _______________________________________________ >> 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/20151211/0b6ff9df/attachment.html From scm.blanc at gmail.com Fri Dec 11 03:44:16 2015 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 11 Dec 2015 09:44:16 +0100 Subject: [Aerogear-users] Health Info Endpoint In-Reply-To: References: <786E2E9282CC0147A0F31612AA2B648F0494573B@apawinmbx01.lan.apa.at> Message-ID: On Fri, Dec 11, 2015 at 9:43 AM, Matthias Wessendorf wrote: > > > On Fri, Dec 11, 2015 at 9:35 AM, Sebastien Blanc > wrote: > >> Hi Michael, >> >> The health endpoint is protected by Keycloak, you can see here the >> different patterns on how the endpoints are protected >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-wildfly/src/main/webapp/WEB-INF/web.xml >> >> I'd not change that. > > > >> Here also a sample on how you could call this endpoint from a third party >> app/lib: >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/node.js/directgranttest.js >> >> Here we create a Push Application but you could adapt it easily to ping >> the health endpoint. >> > > the readme contains some hints on the required Keycloak update for that > > > Actually, isnt it lame the UI does not show the info - somewhere ? > You mean the REST doc ? > > >> >> Sebi >> >> >> On Fri, Dec 11, 2015 at 9:26 AM, Fischelmayer Michael < >> Michael.Fischelmayer at apa.at> wrote: >> >>> Hello, >>> >>> >>> >>> How is the Health Status Enpoint protected? >>> >>> https://SERVER:PORT/CONTEXT/rest/sys/info/health/ >>> >>> >>> >>> I get an 401 but I can?t find the protection method in the rest docu. >>> >>> >>> https://aerogear.org/docs/specs/aerogear-unifiedpush-rest/index.html#-2006359689 >>> >>> >>> >>> Thanks and Regards >>> Michael >>> >>> _______________________________________________ >>> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151211/28d4e7df/attachment.html From matzew at apache.org Fri Dec 11 03:50:02 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 11 Dec 2015 09:50:02 +0100 Subject: [Aerogear-users] Health Info Endpoint In-Reply-To: References: <786E2E9282CC0147A0F31612AA2B648F0494573B@apawinmbx01.lan.apa.at> Message-ID: On Fri, Dec 11, 2015 at 9:44 AM, Sebastien Blanc wrote: > > > On Fri, Dec 11, 2015 at 9:43 AM, Matthias Wessendorf > wrote: > >> >> >> On Fri, Dec 11, 2015 at 9:35 AM, Sebastien Blanc >> wrote: >> >>> Hi Michael, >>> >>> The health endpoint is protected by Keycloak, you can see here the >>> different patterns on how the endpoints are protected >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-wildfly/src/main/webapp/WEB-INF/web.xml >>> >>> I'd not change that. >> >> >> >>> Here also a sample on how you could call this endpoint from a third >>> party app/lib: >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/node.js/directgranttest.js >>> >>> Here we create a Push Application but you could adapt it easily to ping >>> the health endpoint. >>> >> >> the readme contains some hints on the required Keycloak update for that >> >> >> Actually, isnt it lame the UI does not show the info - somewhere ? >> > You mean the REST doc ? > That REST API doc could use some love, yes :-) But I meant more, our own Admin UI - wouldn't it be nice if we have some sort of status UI, displaying whats going on (e.g. green/orange/red) ? -M > >> >>> >>> Sebi >>> >>> >>> On Fri, Dec 11, 2015 at 9:26 AM, Fischelmayer Michael < >>> Michael.Fischelmayer at apa.at> wrote: >>> >>>> Hello, >>>> >>>> >>>> >>>> How is the Health Status Enpoint protected? >>>> >>>> https://SERVER:PORT/CONTEXT/rest/sys/info/health/ >>>> >>>> >>>> >>>> I get an 401 but I can?t find the protection method in the rest docu. >>>> >>>> >>>> https://aerogear.org/docs/specs/aerogear-unifiedpush-rest/index.html#-2006359689 >>>> >>>> >>>> >>>> Thanks and Regards >>>> Michael >>>> >>>> _______________________________________________ >>>> 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 >> >> > > _______________________________________________ > 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/20151211/423cf485/attachment-0001.html From matzew at apache.org Fri Dec 11 04:24:53 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 11 Dec 2015 10:24:53 +0100 Subject: [Aerogear-users] Health Info Endpoint In-Reply-To: References: <786E2E9282CC0147A0F31612AA2B648F0494573B@apawinmbx01.lan.apa.at> Message-ID: FWIW, I created https://issues.jboss.org/browse/AGPUSH-1555 On Fri, Dec 11, 2015 at 9:50 AM, Matthias Wessendorf wrote: > > > On Fri, Dec 11, 2015 at 9:44 AM, Sebastien Blanc > wrote: > >> >> >> On Fri, Dec 11, 2015 at 9:43 AM, Matthias Wessendorf >> wrote: >> >>> >>> >>> On Fri, Dec 11, 2015 at 9:35 AM, Sebastien Blanc >>> wrote: >>> >>>> Hi Michael, >>>> >>>> The health endpoint is protected by Keycloak, you can see here the >>>> different patterns on how the endpoints are protected >>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-wildfly/src/main/webapp/WEB-INF/web.xml >>>> >>>> I'd not change that. >>> >>> >>> >>>> Here also a sample on how you could call this endpoint from a third >>>> party app/lib: >>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/node.js/directgranttest.js >>>> >>>> Here we create a Push Application but you could adapt it easily to ping >>>> the health endpoint. >>>> >>> >>> the readme contains some hints on the required Keycloak update for that >>> >>> >>> Actually, isnt it lame the UI does not show the info - somewhere ? >>> >> You mean the REST doc ? >> > > That REST API doc could use some love, yes :-) > > But I meant more, our own Admin UI - wouldn't it be nice if we have some > sort of status UI, displaying whats going on (e.g. green/orange/red) ? > > -M > > > >> >>> >>>> >>>> Sebi >>>> >>>> >>>> On Fri, Dec 11, 2015 at 9:26 AM, Fischelmayer Michael < >>>> Michael.Fischelmayer at apa.at> wrote: >>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> How is the Health Status Enpoint protected? >>>>> >>>>> https://SERVER:PORT/CONTEXT/rest/sys/info/health/ >>>>> >>>>> >>>>> >>>>> I get an 401 but I can?t find the protection method in the rest docu. >>>>> >>>>> >>>>> https://aerogear.org/docs/specs/aerogear-unifiedpush-rest/index.html#-2006359689 >>>>> >>>>> >>>>> >>>>> Thanks and Regards >>>>> Michael >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> >> _______________________________________________ >> 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/20151211/f3d2b7d9/attachment.html From rob.aerogear at robertwillett.com Fri Dec 11 12:59:29 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Fri, 11 Dec 2015 17:59:29 +0000 Subject: [Aerogear-users] Should the cordova push plugin start the App up if its not started? Message-ID: Hi, We?re trying to work out if the Aerogear Cordova push notification *should* start the app if the app is not started. If the app is in the background than we get the notification but if the app is not started up we don?t *seem* to get anything happening. It seems to work OK when the app is in the foreground or background, just not when its not started up? Should it work when the app is not started on both iOS and Android? Thanks, Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151211/1666f0a3/attachment.html From edewit at redhat.com Mon Dec 14 03:15:50 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 14 Dec 2015 09:15:50 +0100 Subject: [Aerogear-users] Should the cordova push plugin start the App up if its not started? In-Reply-To: References: Message-ID: Hi Rob, Currently this is how background notifications (content-available) should work on iOS, but on Android the notification doesn't start up the app only when the user 'touches' the notification is the app started. I think we could change this behaviour, for instance when you send a notification that doesn't contain any alert message. I think recently some more users have experimented with how to 'enable' background notifications on android. What do you think? p.s. I like your email address On Fri, Dec 11, 2015 at 6:59 PM, Rob Willett wrote: > Hi, > > We?re trying to work out if the Aerogear Cordova push notification > *should* start the app if the app is not started. If the app is in the > background than we get the notification but if the app is not started up we > don?t *seem* to get anything happening. > > It seems to work OK when the app is in the foreground or background, just > not when its not started up? > > Should it work when the app is not started on both iOS and Android? > > Thanks, > > Rob > > _______________________________________________ > 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/20151214/aadae6af/attachment.html From rob.aerogear at robertwillett.com Mon Dec 14 03:36:45 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Mon, 14 Dec 2015 08:36:45 +0000 Subject: [Aerogear-users] Should the cordova push plugin start the App up if its not started? In-Reply-To: References: Message-ID: <275C2666-F9DA-45E9-9533-4FC98CC5CCD8@robertwillett.com> Erik, Our focus has been on iOS and I realise that I should have stated this in my mail message. Apologies. Currently IOS does not start our app when the iPhone receives an AeroGear notification with content-available = 1 in it AND (the app has not been started OR is in the background). Basically we start the iOS app, send a notification to check it works in the foreground. We then swipe up to stop the app, send a new notification down, the new notification is displayed BUT the AeroGear call back to handle the notification is not called. If there is a a magic combination of alert and content-available flags to make this happen we?d be happy to put them in our code but we cannot see anything happening at all. We have not checked Android for this behaviour, as for technical reasons we I broke our last Nexus 5 phone on Friday and have not replaced it yet. We?ll have a new one tomorrow. What we have to do at the moment is check to see if the app has received the silent notification as it will then make a callback to our server, if there has been no callback wishing 60 secs, our server sends a full notification with an alert in that is displayed by the device. The downside to this method is that we lose the ability to clean out old notifications using the silent notification AND a local cordova plugin, local-notifications. Our thinking is that both iOS and Android should start up in the background when they receive a notification with an empty alert AND a content-available = 1 flag AND the app is not running. We could use Apple background-fetch to get 30 secs of processing and then shutdown again. Unclear as to the system on Android. We have also now seen that Apple very aggressively moves Apps from a background state to a suspended state after not very long, which also means that the app doesn?t respond to content-available = 1 flags. We haven?t worked out how long this interval is, but its not hours. This actually underscores the importance of handling the content-available = 1 flag working when apps are suspended or not started. We are really starting to dislike Apples notification implementation. Rob The email address is list specific, we have our own mail servers so its easy to simply use specific emails which we can then track. Its easy to block as well if they get spammed. On 14 Dec 2015, at 8:15, Erik Jan de Wit wrote: > Hi Rob, > > Currently this is how background notifications (content-available) > should > work on iOS, but on Android the notification doesn't start up the app > only > when the user 'touches' the notification is the app started. I think > we > could change this behaviour, for instance when you send a notification > that > doesn't contain any alert message. I think recently some more users > have > experimented with how to 'enable' background notifications on android. > What > do you think? > > p.s. I like your email address > > On Fri, Dec 11, 2015 at 6:59 PM, Rob Willett > > wrote: > >> Hi, >> >> We?re trying to work out if the Aerogear Cordova push notification >> *should* start the app if the app is not started. If the app is in >> the >> background than we get the notification but if the app is not started >> up we >> don?t *seem* to get anything happening. >> >> It seems to work OK when the app is in the foreground or background, >> just >> not when its not started up? >> >> Should it work when the app is not started on both iOS and Android? >> >> Thanks, >> >> Rob >> >> _______________________________________________ >> 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 From edewit at redhat.com Mon Dec 14 05:03:21 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 14 Dec 2015 11:03:21 +0100 Subject: [Aerogear-users] Should the cordova push plugin start the App up if its not started? In-Reply-To: <275C2666-F9DA-45E9-9533-4FC98CC5CCD8@robertwillett.com> References: <275C2666-F9DA-45E9-9533-4FC98CC5CCD8@robertwillett.com> Message-ID: Hi Rob, First of all let's be clear that the 'content-available' flag is a iOS implementation (part of the background fetch) and that it should start your app [1], but this is handled by the OS and there are some heuristics involved that is why you have to set the NewData [2]. So you can't be certain that it will 100% of the time, will start your app. For android we don't have any mechanism atm to enable background notifications, although I think we could add it. [1] https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/index.html#jumpTo_12 [2] https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification On Mon, Dec 14, 2015 at 9:36 AM, Rob Willett wrote: > Erik, > > Our focus has been on iOS and I realise that I should have stated this > in my mail message. Apologies. > > Currently IOS does not start our app when the iPhone receives an > AeroGear notification with content-available = 1 in it AND (the app has > not been started OR is in the background). Basically we start the iOS > app, send a notification to check it works in the foreground. We then > swipe up to stop the app, send a new notification down, the new > notification is displayed BUT the AeroGear call back to handle the > notification is not called. If there is a a magic combination of alert > and content-available flags to make this happen we?d be happy to put > them in our code but we cannot see anything happening at all. We have > not checked Android for this behaviour, as for technical reasons we > I broke our last Nexus 5 phone on Friday and have not > replaced it yet. We?ll have a new one tomorrow. > > What we have to do at the moment is check to see if the app has received > the silent notification as it will then make a callback to our server, > if there has been no callback wishing 60 secs, our server sends a full > notification with an alert in that is displayed by the device. The > downside to this method is that we lose the ability to clean out old > notifications using the silent notification AND a local cordova plugin, > local-notifications. > > Our thinking is that both iOS and Android should start up in the > background when they receive a notification with an empty alert AND a > content-available = 1 flag AND the app is not running. We could use > Apple background-fetch to get 30 secs of processing and then shutdown > again. Unclear as to the system on Android. > > We have also now seen that Apple very aggressively moves Apps from a > background state to a suspended state after not very long, which also > means that the app doesn?t respond to content-available = 1 flags. We > haven?t worked out how long this interval is, but its not hours. This > actually underscores the importance of handling the content-available = > 1 flag working when apps are suspended or not started. > > We are really starting to dislike Apples notification implementation. > > Rob > > The email address is list specific, we have our own mail servers so its > easy to simply use specific emails which we can then track. Its easy to > block as well if they get spammed. > > On 14 Dec 2015, at 8:15, Erik Jan de Wit wrote: > > > Hi Rob, > > > > Currently this is how background notifications (content-available) > > should > > work on iOS, but on Android the notification doesn't start up the app > > only > > when the user 'touches' the notification is the app started. I think > > we > > could change this behaviour, for instance when you send a notification > > that > > doesn't contain any alert message. I think recently some more users > > have > > experimented with how to 'enable' background notifications on android. > > What > > do you think? > > > > p.s. I like your email address > > > > On Fri, Dec 11, 2015 at 6:59 PM, Rob Willett > > >> wrote: > > > >> Hi, > >> > >> We?re trying to work out if the Aerogear Cordova push notification > >> *should* start the app if the app is not started. If the app is in > >> the > >> background than we get the notification but if the app is not started > >> up we > >> don?t *seem* to get anything happening. > >> > >> It seems to work OK when the app is in the foreground or background, > >> just > >> not when its not started up? > >> > >> Should it work when the app is not started on both iOS and Android? > >> > >> Thanks, > >> > >> Rob > >> > >> _______________________________________________ > >> 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 > -- Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151214/402efcc5/attachment.html From rob.aerogear at robertwillett.com Mon Dec 14 05:58:31 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Mon, 14 Dec 2015 10:58:31 +0000 Subject: [Aerogear-users] Should the cordova push plugin start the App up if its not started? In-Reply-To: References: <275C2666-F9DA-45E9-9533-4FC98CC5CCD8@robertwillett.com> Message-ID: Erik, We are aware that the content-available flag is IOS specific. We have also read [1], [2] along with lots the information we can find on background notifications for iOS. I will not say we have read everything as we always find other information buried from Apple :) If we use Table 1 in https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/index.html#jumpTo_12 to make sure we have the same terminology. We can get the iOS Aerogear notification handler to respond to notifications with content-available = 1 when the app is in the **background** and the **foreground**. This works very well. We cannot get the iOS AeroGear notification handler to respond to a notification coming in with content-available = 1 when the app is **suspended**. As far as we can see there is no difference in code for the Aerogear handler to at least wake up and process the event that comes in. The logic to handle the event once woken up is different as there are different flags set. We understand the differences to do with that. Our understanding is that: ```` IF the iOS app is suspended AND a notification comes in with content-available = 1 THEN Wake the app up Pass control to the app through the function defined as the callback in push.register(handleNotification , successHandler) Within the notification handler callback, check to see if the content-available flags is set AND the event.foreground value set. Do something for short while such as get stuff from a server Finish with calling setContentAvailable() with NewData, NoData or Failed depending on what we have done. END ```` Our code for handling the Aerogear notification is very simple, the first thing the Handler does is send a tiny HTTP POST call to our REST server so we can see that the notification handler is being called. Its easy enough to see the Xcode console output when the app is in the foreground or background, but more difficult to track what is happening when the app is starting up. We don?t want to put an alert on the screen as that changes the behaviour of the app, the same for doing a beep or a sound to let us know that the app is starting up. So a simple HTTP POST call to a server with a tiny bit of debugging information is fine. We can see in the server logs this REST call being made in the foreground and in the background but not when the app is suspended. We think we have written the code appropriately but cannot seem to get it to work (if it is supposed to). So we would like to be able to call setContentAvailable(NewData) but we never get the Aerogear handler started to do so. Now we may have missed something vital but the code is pretty simple and works very well in the foreground and background, just not when the app is suspended. So should the AeroGear notification handler be called when the iOS app is suspended as opposed to just in the background? If the notification handler should be called, then we?ll keep digging into our code as it?s a bug with our system. If the Aerogear notification handler is NOT called when the app is suspended and thats by design then we will work out a different mechanism. We are still unclear as to what the Aerogear behaviour should be. Rob On 14 Dec 2015, at 10:03, Erik Jan de Wit wrote: > Hi Rob, > > First of all let's be clear that the 'content-available' flag is a iOS > implementation (part of the background fetch) and that it should start > your > app [1], but this is handled by the OS and there are some heuristics > involved that is why you have to set the NewData [2]. So you can't be > certain that it will 100% of the time, will start your app. > > For android we don't have any mechanism atm to enable background > notifications, although I think we could add it. > > [1] > https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/index.html#jumpTo_12 > [2] > https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification > > On Mon, Dec 14, 2015 at 9:36 AM, Rob Willett > > wrote: > >> Erik, >> >> Our focus has been on iOS and I realise that I should have stated >> this >> in my mail message. Apologies. >> >> Currently IOS does not start our app when the iPhone receives an >> AeroGear notification with content-available = 1 in it AND (the app >> has >> not been started OR is in the background). Basically we start the iOS >> app, send a notification to check it works in the foreground. We then >> swipe up to stop the app, send a new notification down, the new >> notification is displayed BUT the AeroGear call back to handle the >> notification is not called. If there is a a magic combination of >> alert >> and content-available flags to make this happen we?d be happy to >> put >> them in our code but we cannot see anything happening at all. We have >> not checked Android for this behaviour, as for technical reasons we >> I broke our last Nexus 5 phone on Friday and have not >> replaced it yet. We?ll have a new one tomorrow. >> >> What we have to do at the moment is check to see if the app has >> received >> the silent notification as it will then make a callback to our >> server, >> if there has been no callback wishing 60 secs, our server sends a >> full >> notification with an alert in that is displayed by the device. The >> downside to this method is that we lose the ability to clean out old >> notifications using the silent notification AND a local cordova >> plugin, >> local-notifications. >> >> Our thinking is that both iOS and Android should start up in the >> background when they receive a notification with an empty alert AND a >> content-available = 1 flag AND the app is not running. We could use >> Apple background-fetch to get 30 secs of processing and then shutdown >> again. Unclear as to the system on Android. >> >> We have also now seen that Apple very aggressively moves Apps from a >> background state to a suspended state after not very long, which also >> means that the app doesn?t respond to content-available = 1 flags. >> We >> haven?t worked out how long this interval is, but its not hours. >> This >> actually underscores the importance of handling the content-available >> = >> 1 flag working when apps are suspended or not started. >> >> We are really starting to dislike Apples notification implementation. >> >> Rob >> >> The email address is list specific, we have our own mail servers so >> its >> easy to simply use specific emails which we can then track. Its easy >> to >> block as well if they get spammed. >> >> On 14 Dec 2015, at 8:15, Erik Jan de Wit wrote: >> >>> Hi Rob, >>> >>> Currently this is how background notifications (content-available) >>> should >>> work on iOS, but on Android the notification doesn't start up the >>> app >>> only >>> when the user 'touches' the notification is the app started. I think >>> we >>> could change this behaviour, for instance when you send a >>> notification >>> that >>> doesn't contain any alert message. I think recently some more users >>> have >>> experimented with how to 'enable' background notifications on >>> android. >>> What >>> do you think? >>> >>> p.s. I like your email address >>> >>> On Fri, Dec 11, 2015 at 6:59 PM, Rob Willett >>> >>> wrote: >>> >>>> Hi, >>>> >>>> We?re trying to work out if the Aerogear Cordova push >>>> notification >>>> *should* start the app if the app is not started. If the app is in >>>> the >>>> background than we get the notification but if the app is not >>>> started >>>> up we >>>> don?t *seem* to get anything happening. >>>> >>>> It seems to work OK when the app is in the foreground or >>>> background, >>>> just >>>> not when its not started up? >>>> >>>> Should it work when the app is not started on both iOS and Android? >>>> >>>> Thanks, >>>> >>>> Rob >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > 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/20151214/fcb0bdcb/attachment-0001.html From aamagdi at ejada.com Mon Dec 14 06:43:14 2015 From: aamagdi at ejada.com (aamagdi) Date: Mon, 14 Dec 2015 04:43:14 -0700 (MST) Subject: [Aerogear-users] Arabic Characters in Notification In-Reply-To: References: <1449759476978-344.post@n5.nabble.com> <1449759779859-346.post@n5.nabble.com> <1449762192606-348.post@n5.nabble.com> <1449763386732-351.post@n5.nabble.com> Message-ID: <1450093394368-365.post@n5.nabble.com> My server deployment were on Windows machine, I tried to deploy it on Mac OS and it worked fine and got the Arabic notifications correctly on Android. Do you have any suggestion of a specific configuration for Windows? -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/Arabic-Characters-in-Notification-tp344p365.html Sent from the aerogear-users mailing list archive at Nabble.com. From aamagdi at ejada.com Mon Dec 14 06:52:03 2015 From: aamagdi at ejada.com (aamagdi) Date: Mon, 14 Dec 2015 04:52:03 -0700 (MST) Subject: [Aerogear-users] Aerogear Unified Push Server with IBM Websphere Message-ID: <1450093923914-366.post@n5.nabble.com> Hello I was wondering if it is possible to deploy Aerogear UPS on IBM Websphere and is it compatible? -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-Unified-Push-Server-with-IBM-Websphere-tp366.html Sent from the aerogear-users mailing list archive at Nabble.com. From matzew at apache.org Mon Dec 14 06:54:11 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 14 Dec 2015 12:54:11 +0100 Subject: [Aerogear-users] Aerogear Unified Push Server with IBM Websphere In-Reply-To: <1450093923914-366.post@n5.nabble.com> References: <1450093923914-366.post@n5.nabble.com> Message-ID: I dont think so. On Mon, Dec 14, 2015 at 12:52 PM, aamagdi wrote: > Hello > > I was wondering if it is possible to deploy Aerogear UPS on IBM Websphere > and is it compatible? > > > > -- > View this message in context: > http://aerogear-users.1116366.n5.nabble.com/Aerogear-Unified-Push-Server-with-IBM-Websphere-tp366.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/20151214/cdc807ec/attachment.html From aamagdi at ejada.com Mon Dec 14 06:57:09 2015 From: aamagdi at ejada.com (aamagdi) Date: Mon, 14 Dec 2015 04:57:09 -0700 (MST) Subject: [Aerogear-users] Aerogear Unified Push Server with IBM Websphere In-Reply-To: References: <1450093923914-366.post@n5.nabble.com> Message-ID: <1450094229393-368.post@n5.nabble.com> Thanks for you quick response. But is there any dependency between UPS and Wildfly / EAP so I can't deploy it on other App Server? -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/Aerogear-Unified-Push-Server-with-IBM-Websphere-tp366p368.html Sent from the aerogear-users mailing list archive at Nabble.com. From matzew at apache.org Mon Dec 14 07:05:25 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 14 Dec 2015 13:05:25 +0100 Subject: [Aerogear-users] Aerogear Unified Push Server with IBM Websphere In-Reply-To: <1450094229393-368.post@n5.nabble.com> References: <1450093923914-366.post@n5.nabble.com> <1450094229393-368.post@n5.nabble.com> Message-ID: I think some hibernate specifics are used. Also, for the future, we plan to exclusivly go w/ WildFly. e.g. things like FeaturePacks or WildFly Swarm. This will allow you running the server as "java -jar ./myUPS.jar" :) On Mon, Dec 14, 2015 at 12:57 PM, aamagdi wrote: > Thanks for you quick response. > > But is there any dependency between UPS and Wildfly / EAP so I can't deploy > it on other App Server? > > > > -- > View this message in context: > http://aerogear-users.1116366.n5.nabble.com/Aerogear-Unified-Push-Server-with-IBM-Websphere-tp366p368.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/20151214/54768287/attachment.html From rob.aerogear at robertwillett.com Mon Dec 14 16:20:00 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Mon, 14 Dec 2015 21:20:00 +0000 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version Message-ID: Hi, We think we have found a possible bug in the Aerogear Cordova 2.0.4 push plugin specifically on the iOS side. ###Summary### We have two versions of our app, an Android and an IOS version. Both use the latest Cordova push plugin 2.0.4. They also both have the latest Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android versions are compiled at the same time. We are running cordova 5.3.3 with Ionic 1.7.8 (?). 1. We make sure that both apps are NOT started up on each device. We also check they are NOT in the background. 2. We send the same simple notification to each device. This notification config is as below, we have anonymised the variants and alias in this JSON structure, though we can report that the UPS server sends the data correctly. We use the additionalData flag to provide the information necessary to decide which notification has been clicked in the notification drawer. ``` 'variants' => [?variant1?,?variant2? ], 'message' => { 'additionalData' => { 'Disruption_Id' => '107546', 'EpochTime' => '1450125268' }, 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.' }, 'alias' => [ ?alias1? ], 'ttl' => 600 }; ``` 3. Both devices show the message, the Android device stacks the message and the iOS device display an individual message. This looks correct. 4. Clicking on the Android stacked message starts up the app and the Javascript notification handler we have defined, HandleAeroGearNotification is called ``` HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.","badge":"-1"}} ``` 5. Clicking on the notification in the notification drawer on the iOS device also starts our app up correctly but the notification handler, HandleAeroGearNotification(), is NOT called. The app starts up as normal as if the notification had not been clicked. We would expect the notification handler to be called in iOS as it is in Android. 6. All notifications are cleared on both Android and iOS correctly when the app is started up. 6. We define HandleAeroGearNotification as ``` var aeroGearPushConfig = { pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", ios: { variantID: ?variantid_obscured?, variantSecret: ?variant_secret_obscured? } , android: { senderID: "variantid_obscured" , variantID: "variant_id_obscured" , variantSecret: "variant_secret_obscured" } , sendMetricInfo: true, alias: alias1 }; function HandleAeroGearNotification(event) { console.log(?HandleAeroGearNotification: event => ? + JSON.stringify(event)); // Stuff cut for clarity } // Slightly simplified registration event. push.register(HandleAeroGearNotification , function () { console.log(?Success?): } , function () { console.log(?Failure?); } , aeroGearPushConfig); ``` We cannot see any reference to this issue in the JIRA database and wondered if it is a bug or not. If its a bug we are happy to raise it accordingly. Please let us know, Thanks Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151214/c9609458/attachment.html From edewit at redhat.com Tue Dec 15 05:36:55 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 15 Dec 2015 11:36:55 +0100 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: References: Message-ID: Hi Rob, That would be a bug, although I can not reproduce it, to test it this is what I've done to test it: $ > cordova create push-test $ > cordova platform add ios $ > cordova plugin add aerogear-cordova-push copy paste your js code into www/js/index.js onDeviceReady, changed pushServerUrl and variant info and changed quotes to " (this is your email client no doubt) and changed : into ; after console.log("Success") Attach Safari debugger and send a message when the app is in the foreground and get in the console: HandleAeroGearNotification: event => {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} I press the home button and send the app to the background send another message and 'touch' the message to launch the app: HandleAeroGearNotification: event => {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} The I kill the app by pressing home twice and swiping over the app to remove it send another message and 'touch' it to launch the app. This kills my safari debugger so no way to see the console log, but in this case coldstart should be true. To test this better changed the code to alert instead of console: function HandleAeroGearNotification(event) { alert("HandleAeroGearNotification: event => " + event.coldstart); // Stuff cut for clarity } I send another notification 'touch' it to launch the app and see the alert box display the text: HandleAeroGearNotification: event => true Hope this helps On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < rob.aerogear at robertwillett.com> wrote: > Hi, > > We think we have found a possible bug in the Aerogear Cordova 2.0.4 push > plugin specifically on the iOS side. > Summary > > We have two versions of our app, an Android and an IOS version. Both use > the latest Cordova push plugin 2.0.4. They also both have the latest > Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android > versions are compiled at the same time. We are running cordova 5.3.3 with > Ionic 1.7.8 (?). > > 1. > > We make sure that both apps are NOT started up on each device. We also > check they are NOT in the background. > 2. > > We send the same simple notification to each device. This notification > config is as below, we have anonymised the variants and alias in this JSON > structure, though we can report that the UPS server sends the data > correctly. We use the additionalData flag to provide the information > necessary to decide which notification has been clicked in the notification > drawer. > > 'variants' => [?variant1?,?variant2? ], > 'message' => { > 'additionalData' => { 'Disruption_Id' => '107546', > 'EpochTime' => '1450125268' > }, > 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.' }, > 'alias' => [ ?alias1? ], > 'ttl' => 600 > }; > > > 1. > > Both devices show the message, the Android device stacks the message > and the iOS device display an individual message. This looks correct. > 2. > > Clicking on the Android stacked message starts up the app and the > Javascript notification handler we have defined, HandleAeroGearNotification > is called > > HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.","badge":"-1"}} > > > 1. > > Clicking on the notification in the notification drawer on the iOS > device also starts our app up correctly but the notification handler, > HandleAeroGearNotification(), is NOT called. The app starts up as normal as > if the notification had not been clicked. We would expect the notification > handler to be called in iOS as it is in Android. > 2. > > All notifications are cleared on both Android and iOS correctly when > the app is started up. > 3. > > We define HandleAeroGearNotification as > > > var aeroGearPushConfig = { > pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", > ios: { > variantID: ?variantid_obscured?, > variantSecret: ?variant_secret_obscured? > } , > android: { > senderID: "variantid_obscured" , > variantID: "variant_id_obscured" , > variantSecret: "variant_secret_obscured" > } , > sendMetricInfo: true, > alias: alias1 > }; > > function HandleAeroGearNotification(event) { > console.log(?HandleAeroGearNotification: event => ? + JSON.stringify(event)); > > // Stuff cut for clarity > } > > // Slightly simplified registration event. > push.register(HandleAeroGearNotification , function () { > console.log(?Success?): > } , function () { > console.log(?Failure?); > } , aeroGearPushConfig); > > We cannot see any reference to this issue in the JIRA database and > wondered if it is a bug or not. > > If its a bug we are happy to raise it accordingly. > > Please let us know, > > Thanks > > Rob > > _______________________________________________ > 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/20151215/3a4c2a61/attachment-0001.html From edewit at redhat.com Tue Dec 15 07:43:47 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 15 Dec 2015 13:43:47 +0100 Subject: [Aerogear-users] Should the cordova push plugin start the App up if its not started? In-Reply-To: References: <275C2666-F9DA-45E9-9533-4FC98CC5CCD8@robertwillett.com> Message-ID: Hi Rob, Yes it should also start your app when the app is not running or suspended, but it depends on heuristics of how much the user uses your app also something to keep in mind is that: If the user rebooted his device and never launched the app since the reboot, the app will never wake up remotely and if the user killed the app manually from the app switcher, the app will also never wake up remotely. I created a small app similar to your use-case where I do a http request when the content-available flag is set: onNotification: function(event) { if (event['content-available'] === 1) { ajax({ url: "http://192.168.0.30:8888/index.php", dataType: "text" }) .then( function( result ) { console.log(result); push.setContentAvailable(push.FetchResult.NewData); }); } When I send a message with only content-available set like this: ~/w/t/background-fetch ??? curl -u "73795055-123-462d-a6dd-4ad514c3afbf:123456-617f-47d4-a03b-f9ce89b7ec2b" \ -v -H "Accept: application/json" -H "Content-type: application/json" \ -X POST -d \'{"message": {"content-available" : true}}' \https://ups-me.rhcloud.com/ag-push/rest/sender It sometimes calls my server, but not always and sometimes takes some time to activate the app. Again this is something that apple implemented the app is woken up / started by the os and there is nothing we can do about this. You could also send a notification + content-available that way the notification can be used to start the app or if there was no network the app will react before the user 'touches' the app. Hope this clears things up. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151215/f5cd5fb4/attachment.html From rwillett at robertwillett.com Tue Dec 15 09:50:54 2015 From: rwillett at robertwillett.com (Rob Willett) Date: Tue, 15 Dec 2015 14:50:54 +0000 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: References: Message-ID: Erok, Thanks for the informative reply. I?ve been out all day doing family things but I?ll go through this in detail once I get back this evening. You are correct re quotes. We use MailMate for our email client and sometimes strange and wonderful things happen with quotes. The : was a transcription error as we removed a lot of debug code to make the example simpler. We do have this stuff working in the foreground and background :) What you are describing is that we are doing. However I started to put together a tiny dummy app last night to test the issue in isolation and will finish it tonight to see if we get the same results. I agree with everything you say apart from the bit after killing it, touch a notification and it being seen as an alert (thats the bit we cannot get working). I?d be delighted if its our code at fault, embarrassed but delighted. From a quick perusal of your code I *think* we are doing exactly what you are doing. Let me go through it later and I?ll come back, Best wishes, Rob On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote: > Hi Rob, > > That would be a bug, although I can not reproduce it, to test it this > is > what I've done to test it: > > $ > cordova create push-test > $ > cordova platform add ios > $ > cordova plugin add aerogear-cordova-push > > copy paste your js code into www/js/index.js onDeviceReady, changed > pushServerUrl and variant info and changed quotes to " (this is your > email > client no doubt) and changed : into ; after console.log("Success") > > > Attach Safari debugger and send a message when the app is in the > foreground > and get in the console: > > HandleAeroGearNotification: event => > {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > I press the home button and send the app to the background send > another > message and 'touch' the message to launch the app: > > HandleAeroGearNotification: event => > {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > The I kill the app by pressing home twice and swiping over the app to > remove it send another message and 'touch' it to launch the app. This > kills > my safari debugger so no way to see the console log, but in this case > coldstart should be true. To test this better changed the code to > alert > instead of console: > > function HandleAeroGearNotification(event) { > alert("HandleAeroGearNotification: event => " + event.coldstart); > > // Stuff cut for clarity > } > > I send another notification 'touch' it to launch the app and see the > alert > box display the text: > > HandleAeroGearNotification: event => true > > Hope this helps > > > > On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < > rob.aerogear at robertwillett.com> wrote: > >> Hi, >> >> We think we have found a possible bug in the Aerogear Cordova 2.0.4 >> push >> plugin specifically on the iOS side. >> Summary >> >> We have two versions of our app, an Android and an IOS version. Both >> use >> the latest Cordova push plugin 2.0.4. They also both have the latest >> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android >> versions are compiled at the same time. We are running cordova 5.3.3 >> with >> Ionic 1.7.8 (?). >> >> 1. >> >> We make sure that both apps are NOT started up on each device. We >> also >> check they are NOT in the background. >> 2. >> >> We send the same simple notification to each device. This >> notification >> config is as below, we have anonymised the variants and alias in this >> JSON >> structure, though we can report that the UPS server sends the data >> correctly. We use the additionalData flag to provide the information >> necessary to decide which notification has been clicked in the >> notification >> drawer. >> >> 'variants' => [?variant1?,?variant2? ], >> 'message' => { >> 'additionalData' => { 'Disruption_Id' => '107546', >> 'EpochTime' => '1450125268' >> }, >> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of >> King William Street - To facilitate a heavy lift in Cannon Street, >> Cannon Street will be closed. Traffic is slow moving on diversion.' >> }, >> 'alias' => [ ?alias1? ], >> 'ttl' => 600 >> }; >> >> >> 1. >> >> Both devices show the message, the Android device stacks the message >> and the iOS device display an individual message. This looks correct. >> 2. >> >> Clicking on the Android stacked message starts up the app and the >> Javascript notification handler we have defined, >> HandleAeroGearNotification >> is called >> >> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) >> (All Directions) at the junction of King William Street - To >> facilitate a heavy lift in Cannon Street, Cannon Street will be >> closed. Traffic is slow moving on >> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon >> Street (EC4N) (All Directions) at the junction of King William Street >> - To facilitate a heavy lift in Cannon Street, Cannon Street will be >> closed. Traffic is slow moving on diversion.","badge":"-1"}} >> >> >> 1. >> >> Clicking on the notification in the notification drawer on the iOS >> device also starts our app up correctly but the notification handler, >> HandleAeroGearNotification(), is NOT called. The app starts up as >> normal as >> if the notification had not been clicked. We would expect the >> notification >> handler to be called in iOS as it is in Android. >> 2. >> >> All notifications are cleared on both Android and iOS correctly when >> the app is started up. >> 3. >> >> We define HandleAeroGearNotification as >> >> >> var aeroGearPushConfig = { >> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >> ios: { >> variantID: ?variantid_obscured?, >> variantSecret: ?variant_secret_obscured? >> } , >> android: { >> senderID: "variantid_obscured" , >> variantID: "variant_id_obscured" , >> variantSecret: "variant_secret_obscured" >> } , >> sendMetricInfo: true, >> alias: alias1 >> }; >> >> function HandleAeroGearNotification(event) { >> console.log(?HandleAeroGearNotification: event => ? + >> JSON.stringify(event)); >> >> // Stuff cut for clarity >> } >> >> // Slightly simplified registration event. >> push.register(HandleAeroGearNotification , function () { >> console.log(?Success?): >> } , function () { >> console.log(?Failure?); >> } , aeroGearPushConfig); >> >> We cannot see any reference to this issue in the JIRA database and >> wondered if it is a bug or not. >> >> If its a bug we are happy to raise it accordingly. >> >> Please let us know, >> >> Thanks >> >> Rob >> >> _______________________________________________ >> 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 From rob.aerogear at robertwillett.com Tue Dec 15 09:57:59 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Tue, 15 Dec 2015 14:57:59 +0000 Subject: [Aerogear-users] Should the cordova push plugin start the App up if its not started? In-Reply-To: References: <275C2666-F9DA-45E9-9533-4FC98CC5CCD8@robertwillett.com> Message-ID: On 15 Dec 2015, at 12:43, Erik Jan de Wit wrote: ``` > Yes it should also start your app when the app is not running or > suspended, > but it depends on heuristics of how much the user uses your app also > something to keep in mind is that: ``` These heuristics seem arbitrary and undefined to us. ``` > If the user rebooted his device and never launched the app since the > reboot, the app will never wake up remotely and if the user killed the > app > manually from the app switcher, the app will also never wake up > remotely. ``` So basically the user has to start the app and never kill it. Just put it to the background and leave it there. ``` > I created a small app similar to your use-case where I do a http > request > when the content-available flag is set: > > onNotification: function(event) { > if (event['content-available'] === 1) { > ajax({ > url: "http://192.168.0.30:8888/index.php", > dataType: "text" > }) > .then( function( result ) { > console.log(result); > push.setContentAvailable(push.FetchResult.NewData); > }); > } > When I send a message with only content-available set like this: > > ~/w/t/background-fetch ??? curl -u > "73795055-123-462d-a6dd-4ad514c3afbf:123456-617f-47d4-a03b-f9ce89b7ec2b" > \ > -v -H "Accept: application/json" -H "Content-type: application/json" > \ > -X POST -d \'{"message": {"content-available" : true}}' > \https://ups-me.rhcloud.com/ag-push/rest/sender > > > It sometimes calls my server, but not always and sometimes takes some > time > to activate the app. Again this is something that apple implemented > the app > is woken up / started by the os and there is nothing we can do about > this. > > You could also send a notification + content-available that way the > notification can be used to start the app or if there was no network > the > app will react before the user 'touches' the app. ``` Mmmm this is similar to what happens to our code. We have had things happen in the background or suspended state (or what we thought was suspended), but its not clear whats going on. We haven?t had success recently hence our e-mail, we?ll keep looking into this and see if we can get anything clearer. One option was to look at doing an explicit background fetch every hour or so, to see if we can jiggle the app into a better state or to clear out local notifications. It may well be that we are pushing Apples idea of what notifications can or should do just too far and we should accept the limitations and work with them. We had tried the content-available AND a notification but that didn?t seem to work. We?ll try again now we have a better understanding. Thanks again. Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151215/d12a17ba/attachment.html From rob.aerogear at robertwillett.com Wed Dec 16 02:50:29 2015 From: rob.aerogear at robertwillett.com (rob Willett) Date: Wed, 16 Dec 2015 07:50:29 +0000 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: References: Message-ID: <8CAB9E22-F3EA-451B-9872-729A8170DEDF@robertwillett.com> Erik, We have built our own test using a cordova startup, much the same as you have outlined below, using our own JS code and it works OK. We get the same results. However when we run our app (with the code from above) we still get the same error as before. So clearly the Aerogear plugin does work and something in our code, or in the Ionic framework we are using, is causing a problem specifically to IOS. We spent a couple of hours late yesterday going through our code trying to see what, if anything was causing the issue but nothing positive emerged. So the problem is ours to solve, we will keep looking at pulling code out until it works. We?ll also reproduce the simple test but using the Ionic framework to see if thats the problem. Our thinking has to be that its our code and theres some sort of race or timing condition we are introducing. Thanks again, sadly we have a lot of work to do today. Best wishes, Rob On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote: > Hi Rob, > > That would be a bug, although I can not reproduce it, to test it this > is > what I've done to test it: > > $ > cordova create push-test > $ > cordova platform add ios > $ > cordova plugin add aerogear-cordova-push > > copy paste your js code into www/js/index.js onDeviceReady, changed > pushServerUrl and variant info and changed quotes to " (this is your > email > client no doubt) and changed : into ; after console.log("Success") > > > Attach Safari debugger and send a message when the app is in the > foreground > and get in the console: > > HandleAeroGearNotification: event => > {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > I press the home button and send the app to the background send > another > message and 'touch' the message to launch the app: > > HandleAeroGearNotification: event => > {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > The I kill the app by pressing home twice and swiping over the app to > remove it send another message and 'touch' it to launch the app. This > kills > my safari debugger so no way to see the console log, but in this case > coldstart should be true. To test this better changed the code to > alert > instead of console: > > function HandleAeroGearNotification(event) { > alert("HandleAeroGearNotification: event => " + event.coldstart); > > // Stuff cut for clarity > } > > I send another notification 'touch' it to launch the app and see the > alert > box display the text: > > HandleAeroGearNotification: event => true > > Hope this helps > > > > On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < > rob.aerogear at robertwillett.com> wrote: > >> Hi, >> >> We think we have found a possible bug in the Aerogear Cordova 2.0.4 >> push >> plugin specifically on the iOS side. >> Summary >> >> We have two versions of our app, an Android and an IOS version. Both >> use >> the latest Cordova push plugin 2.0.4. They also both have the latest >> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android >> versions are compiled at the same time. We are running cordova 5.3.3 >> with >> Ionic 1.7.8 (?). >> >> 1. >> >> We make sure that both apps are NOT started up on each device. We >> also >> check they are NOT in the background. >> 2. >> >> We send the same simple notification to each device. This >> notification >> config is as below, we have anonymised the variants and alias in this >> JSON >> structure, though we can report that the UPS server sends the data >> correctly. We use the additionalData flag to provide the information >> necessary to decide which notification has been clicked in the >> notification >> drawer. >> >> 'variants' => [?variant1?,?variant2? ], >> 'message' => { >> 'additionalData' => { 'Disruption_Id' => '107546', >> 'EpochTime' => '1450125268' >> }, >> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of >> King William Street - To facilitate a heavy lift in Cannon Street, >> Cannon Street will be closed. Traffic is slow moving on diversion.' >> }, >> 'alias' => [ ?alias1? ], >> 'ttl' => 600 >> }; >> >> >> 1. >> >> Both devices show the message, the Android device stacks the message >> and the iOS device display an individual message. This looks correct. >> 2. >> >> Clicking on the Android stacked message starts up the app and the >> Javascript notification handler we have defined, >> HandleAeroGearNotification >> is called >> >> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) >> (All Directions) at the junction of King William Street - To >> facilitate a heavy lift in Cannon Street, Cannon Street will be >> closed. Traffic is slow moving on >> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon >> Street (EC4N) (All Directions) at the junction of King William Street >> - To facilitate a heavy lift in Cannon Street, Cannon Street will be >> closed. Traffic is slow moving on diversion.","badge":"-1"}} >> >> >> 1. >> >> Clicking on the notification in the notification drawer on the iOS >> device also starts our app up correctly but the notification handler, >> HandleAeroGearNotification(), is NOT called. The app starts up as >> normal as >> if the notification had not been clicked. We would expect the >> notification >> handler to be called in iOS as it is in Android. >> 2. >> >> All notifications are cleared on both Android and iOS correctly when >> the app is started up. >> 3. >> >> We define HandleAeroGearNotification as >> >> >> var aeroGearPushConfig = { >> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >> ios: { >> variantID: ?variantid_obscured?, >> variantSecret: ?variant_secret_obscured? >> } , >> android: { >> senderID: "variantid_obscured" , >> variantID: "variant_id_obscured" , >> variantSecret: "variant_secret_obscured" >> } , >> sendMetricInfo: true, >> alias: alias1 >> }; >> >> function HandleAeroGearNotification(event) { >> console.log(?HandleAeroGearNotification: event => ? + >> JSON.stringify(event)); >> >> // Stuff cut for clarity >> } >> >> // Slightly simplified registration event. >> push.register(HandleAeroGearNotification , function () { >> console.log(?Success?): >> } , function () { >> console.log(?Failure?); >> } , aeroGearPushConfig); >> >> We cannot see any reference to this issue in the JIRA database and >> wondered if it is a bug or not. >> >> If its a bug we are happy to raise it accordingly. >> >> Please let us know, >> >> Thanks >> >> Rob >> >> _______________________________________________ >> 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 From rob.aerogear at robertwillett.com Wed Dec 16 10:54:27 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Wed, 16 Dec 2015 15:54:27 +0000 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: References: Message-ID: Erik, We have built the simplest possible app we can that uses the Aerogear push plugin but using the ionic tabs starter kit. http://ionicframework.com/getting-started/ We have taken the code directly from the Cordova simple app that we have got working and put it into the Ionic app. if we follow your tests as below: 1. IOS App in foreground, we send a simple push notification from the Aerogear console - Works OK, We can see the event. Good 2. IOS App in background, we send a simple push notification from the Aerogear console - Works OK, We can see the event. Good 3. IOS App killed, we send a simple push notification from the Aerogear console and some of the time when we click on the notification in the notification drawer we do NOT get the notification handler called. Not so good However it does appear to work most of the time with our minimal Ionic app, but some of the time it fails. We had a run of 1 in 2 failures when we click on the notification. Now we have just done 20 runs in a row, each time killing the app after receiving the notification and not a single failure. Nothing changed. We cannot find any obvious reason for this so we are still investigating. We have reconfigured our main app to work the same way as the minimal app but we are still getting the same issues as before, we can see the notification in the drawer but clicking on it does NOT call the same handler with the same code as the minimal app. We get zero calls to the notification event handler. We are wondering if there is a timing issue somewhere in our code, but we can?t see it. We also wondered if the size of the code we are loading is the cause of a timing issue as well. Is there any way of adding more debugging into the Aerogear push plugin to see if we can track things down that way? Its very frustrating, but thanks for your help to date. It does look like its an interaction with our code, Ionic and the Aerogear plugin. My money is on our code though. We?ll now start pulling working code out of our app until we get back to the minimal app. Only 18,604 lines to go :) Rob On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote: > Hi Rob, > > That would be a bug, although I can not reproduce it, to test it this > is > what I've done to test it: > $ > cordova create push-test > $ > cordova platform add ios > $ > cordova plugin add aerogear-cordova-push > > copy paste your js code into www/js/index.js onDeviceReady, changed > pushServerUrl and variant info and changed quotes to " (this is your > email > client no doubt) and changed : into ; after console.log("Success") > > > Attach Safari debugger and send a message when the app is in the > foreground > and get in the console: > > HandleAeroGearNotification: event => > {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > I press the home button and send the app to the background send > another > message and 'touch' the message to launch the app: > > HandleAeroGearNotification: event => > {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > The I kill the app by pressing home twice and swiping over the app to > remove it send another message and 'touch' it to launch the app. This > kills > my safari debugger so no way to see the console log, but in this case > coldstart should be true. To test this better changed the code to > alert > instead of console: > > function HandleAeroGearNotification(event) { > alert("HandleAeroGearNotification: event => " + event.coldstart); > > // Stuff cut for clarity > } > > I send another notification 'touch' it to launch the app and see the > alert > box display the text: > > HandleAeroGearNotification: event => true > > Hope this helps > > > > On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < > rob.aerogear at robertwillett.com> wrote: > >> Hi, >> >> We think we have found a possible bug in the Aerogear Cordova 2.0.4 >> push >> plugin specifically on the iOS side. >> Summary >> >> We have two versions of our app, an Android and an IOS version. Both >> use >> the latest Cordova push plugin 2.0.4. They also both have the latest >> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android >> versions are compiled at the same time. We are running cordova 5.3.3 >> with >> Ionic 1.7.8 (?). >> >> 1. >> >> We make sure that both apps are NOT started up on each device. We >> also >> check they are NOT in the background. >> 2. >> >> We send the same simple notification to each device. This >> notification >> config is as below, we have anonymised the variants and alias in this >> JSON >> structure, though we can report that the UPS server sends the data >> correctly. We use the additionalData flag to provide the information >> necessary to decide which notification has been clicked in the >> notification >> drawer. >> >> 'variants' => [?variant1?,?variant2? ], >> 'message' => { >> 'additionalData' => { 'Disruption_Id' => '107546', >> 'EpochTime' => '1450125268' >> }, >> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of >> King William Street - To facilitate a heavy lift in Cannon Street, >> Cannon Street will be closed. Traffic is slow moving on diversion.' >> }, >> 'alias' => [ ?alias1? ], >> 'ttl' => 600 >> }; >> >> >> 1. >> >> Both devices show the message, the Android device stacks the message >> and the iOS device display an individual message. This looks correct. >> 2. >> >> Clicking on the Android stacked message starts up the app and the >> Javascript notification handler we have defined, >> HandleAeroGearNotification >> is called >> >> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) >> (All Directions) at the junction of King William Street - To >> facilitate a heavy lift in Cannon Street, Cannon Street will be >> closed. Traffic is slow moving on >> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon >> Street (EC4N) (All Directions) at the junction of King William Street >> - To facilitate a heavy lift in Cannon Street, Cannon Street will be >> closed. Traffic is slow moving on diversion.","badge":"-1"}} >> >> >> 1. >> >> Clicking on the notification in the notification drawer on the iOS >> device also starts our app up correctly but the notification handler, >> HandleAeroGearNotification(), is NOT called. The app starts up as >> normal as >> if the notification had not been clicked. We would expect the >> notification >> handler to be called in iOS as it is in Android. >> 2. >> >> All notifications are cleared on both Android and iOS correctly when >> the app is started up. >> 3. >> >> We define HandleAeroGearNotification as >> >> >> var aeroGearPushConfig = { >> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >> ios: { >> variantID: ?variantid_obscured?, >> variantSecret: ?variant_secret_obscured? >> } , >> android: { >> senderID: "variantid_obscured" , >> variantID: "variant_id_obscured" , >> variantSecret: "variant_secret_obscured" >> } , >> sendMetricInfo: true, >> alias: alias1 >> }; >> >> function HandleAeroGearNotification(event) { >> console.log(?HandleAeroGearNotification: event => ? + >> JSON.stringify(event)); >> >> // Stuff cut for clarity >> } >> >> // Slightly simplified registration event. >> push.register(HandleAeroGearNotification , function () { >> console.log(?Success?): >> } , function () { >> console.log(?Failure?); >> } , aeroGearPushConfig); >> >> We cannot see any reference to this issue in the JIRA database and >> wondered if it is a bug or not. >> >> If its a bug we are happy to raise it accordingly. >> >> Please let us know, >> >> Thanks >> >> Rob >> >> _______________________________________________ >> 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 From scm.blanc at gmail.com Wed Dec 16 11:04:16 2015 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 16 Dec 2015 17:04:16 +0100 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: References: Message-ID: In the ionic app when do you do the registration of UPS ? on the platformReady event ? On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett wrote: > Erik, > > We have built the simplest possible app we can that uses the Aerogear > push plugin but using the ionic tabs starter kit. > > http://ionicframework.com/getting-started/ > > We have taken the code directly from the Cordova simple app that we have > got working and put it into the Ionic app. > > if we follow your tests as below: > > 1. IOS App in foreground, we send a simple push notification from the > Aerogear console - Works OK, We can see the event. Good > > 2. IOS App in background, we send a simple push notification from the > Aerogear console - Works OK, We can see the event. Good > > 3. IOS App killed, we send a simple push notification from the Aerogear > console and some of the time when we click on the notification in the > notification drawer we do NOT get the notification handler called. Not > so good > > However it does appear to work most of the time with our minimal Ionic > app, but some of the time it fails. We had a run of 1 in 2 failures when > we click on the notification. Now we have just done 20 runs in a row, > each time killing the app after receiving the notification and not a > single failure. Nothing changed. > > We cannot find any obvious reason for this so we are still > investigating. > > We have reconfigured our main app to work the same way as the minimal > app but we are still getting the same issues as before, we can see the > notification in the drawer but clicking on it does NOT call the same > handler with the same code as the minimal app. We get zero calls to the > notification event handler. > > We are wondering if there is a timing issue somewhere in our code, but > we can?t see it. We also wondered if the size of the code we are > loading is the cause of a timing issue as well. > > Is there any way of adding more debugging into the Aerogear push plugin > to see if we can track things down that way? > > Its very frustrating, but thanks for your help to date. It does look > like its an interaction with our code, Ionic and the Aerogear plugin. My > money is on our code though. We?ll now start pulling working code out > of our app until we get back to the minimal app. Only 18,604 lines to go > :) > > Rob > > On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote: > > > Hi Rob, > > > > That would be a bug, although I can not reproduce it, to test it this > > is > > what I've done to test it: > > $ > cordova create push-test > > $ > cordova platform add ios > > $ > cordova plugin add aerogear-cordova-push > > > > copy paste your js code into www/js/index.js onDeviceReady, changed > > pushServerUrl and variant info and changed quotes to " (this is your > > email > > client no doubt) and changed : into ; after console.log("Success") > > > > > > Attach Safari debugger and send a message when the app is in the > > foreground > > and get in the console: > > > > HandleAeroGearNotification: event => > > > {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > > > I press the home button and send the app to the background send > > another > > message and 'touch' the message to launch the app: > > > > HandleAeroGearNotification: event => > > > {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > > > The I kill the app by pressing home twice and swiping over the app to > > remove it send another message and 'touch' it to launch the app. This > > kills > > my safari debugger so no way to see the console log, but in this case > > coldstart should be true. To test this better changed the code to > > alert > > instead of console: > > > > function HandleAeroGearNotification(event) { > > alert("HandleAeroGearNotification: event => " + event.coldstart); > > > > // Stuff cut for clarity > > } > > > > I send another notification 'touch' it to launch the app and see the > > alert > > box display the text: > > > > HandleAeroGearNotification: event => true > > > > Hope this helps > > > > > > > > On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < > > rob.aerogear at robertwillett.com> wrote: > > > >> Hi, > >> > >> We think we have found a possible bug in the Aerogear Cordova 2.0.4 > >> push > >> plugin specifically on the iOS side. > >> Summary > >> > >> We have two versions of our app, an Android and an IOS version. Both > >> use > >> the latest Cordova push plugin 2.0.4. They also both have the latest > >> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android > >> versions are compiled at the same time. We are running cordova 5.3.3 > >> with > >> Ionic 1.7.8 (?). > >> > >> 1. > >> > >> We make sure that both apps are NOT started up on each device. We > >> also > >> check they are NOT in the background. > >> 2. > >> > >> We send the same simple notification to each device. This > >> notification > >> config is as below, we have anonymised the variants and alias in this > >> JSON > >> structure, though we can report that the UPS server sends the data > >> correctly. We use the additionalData flag to provide the information > >> necessary to decide which notification has been clicked in the > >> notification > >> drawer. > >> > >> 'variants' => [?variant1?,?variant2? ], > >> 'message' => { > >> 'additionalData' => { 'Disruption_Id' => '107546', > >> 'EpochTime' => '1450125268' > >> }, > >> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of > >> King William Street - To facilitate a heavy lift in Cannon Street, > >> Cannon Street will be closed. Traffic is slow moving on diversion.' > >> }, > >> 'alias' => [ ?alias1? ], > >> 'ttl' => 600 > >> }; > >> > >> > >> 1. > >> > >> Both devices show the message, the Android device stacks the message > >> and the iOS device display an individual message. This looks correct. > >> 2. > >> > >> Clicking on the Android stacked message starts up the app and the > >> Javascript notification handler we have defined, > >> HandleAeroGearNotification > >> is called > >> > >> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) > >> (All Directions) at the junction of King William Street - To > >> facilitate a heavy lift in Cannon Street, Cannon Street will be > >> closed. Traffic is slow moving on > >> > diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon > >> Street (EC4N) (All Directions) at the junction of King William Street > >> - To facilitate a heavy lift in Cannon Street, Cannon Street will be > >> closed. Traffic is slow moving on diversion.","badge":"-1"}} > >> > >> > >> 1. > >> > >> Clicking on the notification in the notification drawer on the iOS > >> device also starts our app up correctly but the notification handler, > >> HandleAeroGearNotification(), is NOT called. The app starts up as > >> normal as > >> if the notification had not been clicked. We would expect the > >> notification > >> handler to be called in iOS as it is in Android. > >> 2. > >> > >> All notifications are cleared on both Android and iOS correctly when > >> the app is started up. > >> 3. > >> > >> We define HandleAeroGearNotification as > >> > >> > >> var aeroGearPushConfig = { > >> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", > >> ios: { > >> variantID: ?variantid_obscured?, > >> variantSecret: ?variant_secret_obscured? > >> } , > >> android: { > >> senderID: "variantid_obscured" , > >> variantID: "variant_id_obscured" , > >> variantSecret: "variant_secret_obscured" > >> } , > >> sendMetricInfo: true, > >> alias: alias1 > >> }; > >> > >> function HandleAeroGearNotification(event) { > >> console.log(?HandleAeroGearNotification: event => ? + > >> JSON.stringify(event)); > >> > >> // Stuff cut for clarity > >> } > >> > >> // Slightly simplified registration event. > >> push.register(HandleAeroGearNotification , function () { > >> console.log(?Success?): > >> } , function () { > >> console.log(?Failure?); > >> } , aeroGearPushConfig); > >> > >> We cannot see any reference to this issue in the JIRA database and > >> wondered if it is a bug or not. > >> > >> If its a bug we are happy to raise it accordingly. > >> > >> Please let us know, > >> > >> Thanks > >> > >> Rob > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151216/c57c30cd/attachment-0001.html From rob.aerogear at robertwillett.com Wed Dec 16 11:14:24 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Wed, 16 Dec 2015 16:14:24 +0000 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: References: Message-ID: <783F9E55-54CC-4C9E-857F-64A03DB1BC96@robertwillett.com> Sebastien Yes, we do it at that point, $ionicPlatform.ready. I include the whole of that area of code for reference but we?re not expecting you to debug it for us. Merely to demonstrate its there. At the moment all we want the code to do is put an alert up. ``` .run(function($ionicPlatform , CordovaService) { $ionicPlatform.ready(function() { if (window.StatusBar) { // org.apache.cordova.statusbar required StatusBar.styleDefault(); } ConsoleLog('<<< Cordova ready >>>'); /* This seems to remove an annoying page flicker on iOS when the keyboard is displayed */ cordova.plugins.Keyboard.disableScroll(true); isDeviceReady = true; var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app"; var aeroGearPushConfig = { pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", ios: { variantID: ?XXXXX?, variantSecret: ?YYYYYYY? } , // sendMetricInfo: true, alias: uuid }; push.register(function (event) { alert("EVENT = " + JSON.stringify(event)); } , function () { if (1) { // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid)); // ConsoleLog("UUID = " + uuid); } } , function () { } , aeroGearPushConfig); ``` We were still loading up another 18,000 lines of code so we need to start pruning that back until we have something that works. Rob On 16 Dec 2015, at 16:04, Sebastien Blanc wrote: > In the ionic app when do you do the registration of UPS ? on the > platformReady event ? > > On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett > > wrote: > >> Erik, >> >> We have built the simplest possible app we can that uses the Aerogear >> push plugin but using the ionic tabs starter kit. >> >> http://ionicframework.com/getting-started/ >> >> We have taken the code directly from the Cordova simple app that we >> have >> got working and put it into the Ionic app. >> >> if we follow your tests as below: >> >> 1. IOS App in foreground, we send a simple push notification from the >> Aerogear console - Works OK, We can see the event. Good >> >> 2. IOS App in background, we send a simple push notification from the >> Aerogear console - Works OK, We can see the event. Good >> >> 3. IOS App killed, we send a simple push notification from the >> Aerogear >> console and some of the time when we click on the notification in the >> notification drawer we do NOT get the notification handler called. >> Not >> so good >> >> However it does appear to work most of the time with our minimal >> Ionic >> app, but some of the time it fails. We had a run of 1 in 2 failures >> when >> we click on the notification. Now we have just done 20 runs in a row, >> each time killing the app after receiving the notification and not a >> single failure. Nothing changed. >> >> We cannot find any obvious reason for this so we are still >> investigating. >> >> We have reconfigured our main app to work the same way as the minimal >> app but we are still getting the same issues as before, we can see >> the >> notification in the drawer but clicking on it does NOT call the same >> handler with the same code as the minimal app. We get zero calls to >> the >> notification event handler. >> >> We are wondering if there is a timing issue somewhere in our code, >> but >> we can?t see it. We also wondered if the size of the code we are >> loading is the cause of a timing issue as well. >> >> Is there any way of adding more debugging into the Aerogear push >> plugin >> to see if we can track things down that way? >> >> Its very frustrating, but thanks for your help to date. It does look >> like its an interaction with our code, Ionic and the Aerogear plugin. >> My >> money is on our code though. We?ll now start pulling working code >> out >> of our app until we get back to the minimal app. Only 18,604 lines to >> go >> :) >> >> Rob >> >> On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote: >> >>> Hi Rob, >>> >>> That would be a bug, although I can not reproduce it, to test it >>> this >>> is >>> what I've done to test it: >>> $ > cordova create push-test >>> $ > cordova platform add ios >>> $ > cordova plugin add aerogear-cordova-push >>> >>> copy paste your js code into www/js/index.js onDeviceReady, changed >>> pushServerUrl and variant info and changed quotes to " (this is your >>> email >>> client no doubt) and changed : into ; after console.log("Success") >>> >>> >>> Attach Safari debugger and send a message when the app is in the >>> foreground >>> and get in the console: >>> >>> HandleAeroGearNotification: event => >>> >> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} >>> >>> I press the home button and send the app to the background send >>> another >>> message and 'touch' the message to launch the app: >>> >>> HandleAeroGearNotification: event => >>> >> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} >>> >>> The I kill the app by pressing home twice and swiping over the app >>> to >>> remove it send another message and 'touch' it to launch the app. >>> This >>> kills >>> my safari debugger so no way to see the console log, but in this >>> case >>> coldstart should be true. To test this better changed the code to >>> alert >>> instead of console: >>> >>> function HandleAeroGearNotification(event) { >>> alert("HandleAeroGearNotification: event => " + event.coldstart); >>> >>> // Stuff cut for clarity >>> } >>> >>> I send another notification 'touch' it to launch the app and see the >>> alert >>> box display the text: >>> >>> HandleAeroGearNotification: event => true >>> >>> Hope this helps >>> >>> >>> >>> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < >>> rob.aerogear at robertwillett.com> wrote: >>> >>>> Hi, >>>> >>>> We think we have found a possible bug in the Aerogear Cordova 2.0.4 >>>> push >>>> plugin specifically on the iOS side. >>>> Summary >>>> >>>> We have two versions of our app, an Android and an IOS version. >>>> Both >>>> use >>>> the latest Cordova push plugin 2.0.4. They also both have the >>>> latest >>>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and >>>> Android >>>> versions are compiled at the same time. We are running cordova >>>> 5.3.3 >>>> with >>>> Ionic 1.7.8 (?). >>>> >>>> 1. >>>> >>>> We make sure that both apps are NOT started up on each device. We >>>> also >>>> check they are NOT in the background. >>>> 2. >>>> >>>> We send the same simple notification to each device. This >>>> notification >>>> config is as below, we have anonymised the variants and alias in >>>> this >>>> JSON >>>> structure, though we can report that the UPS server sends the data >>>> correctly. We use the additionalData flag to provide the >>>> information >>>> necessary to decide which notification has been clicked in the >>>> notification >>>> drawer. >>>> >>>> 'variants' => [?variant1?,?variant2? ], >>>> 'message' => { >>>> 'additionalData' => { 'Disruption_Id' => '107546', >>>> 'EpochTime' => '1450125268' >>>> }, >>>> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction >>>> of >>>> King William Street - To facilitate a heavy lift in Cannon Street, >>>> Cannon Street will be closed. Traffic is slow moving on diversion.' >>>> }, >>>> 'alias' => [ ?alias1? ], >>>> 'ttl' => 600 >>>> }; >>>> >>>> >>>> 1. >>>> >>>> Both devices show the message, the Android device stacks the >>>> message >>>> and the iOS device display an individual message. This looks >>>> correct. >>>> 2. >>>> >>>> Clicking on the Android stacked message starts up the app and the >>>> Javascript notification handler we have defined, >>>> HandleAeroGearNotification >>>> is called >>>> >>>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) >>>> (All Directions) at the junction of King William Street - To >>>> facilitate a heavy lift in Cannon Street, Cannon Street will be >>>> closed. Traffic is slow moving on >>>> >> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon >>>> Street (EC4N) (All Directions) at the junction of King William >>>> Street >>>> - To facilitate a heavy lift in Cannon Street, Cannon Street will >>>> be >>>> closed. Traffic is slow moving on diversion.","badge":"-1"}} >>>> >>>> >>>> 1. >>>> >>>> Clicking on the notification in the notification drawer on the iOS >>>> device also starts our app up correctly but the notification >>>> handler, >>>> HandleAeroGearNotification(), is NOT called. The app starts up as >>>> normal as >>>> if the notification had not been clicked. We would expect the >>>> notification >>>> handler to be called in iOS as it is in Android. >>>> 2. >>>> >>>> All notifications are cleared on both Android and iOS correctly >>>> when >>>> the app is started up. >>>> 3. >>>> >>>> We define HandleAeroGearNotification as >>>> >>>> >>>> var aeroGearPushConfig = { >>>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >>>> ios: { >>>> variantID: ?variantid_obscured?, >>>> variantSecret: ?variant_secret_obscured? >>>> } , >>>> android: { >>>> senderID: "variantid_obscured" , >>>> variantID: "variant_id_obscured" , >>>> variantSecret: "variant_secret_obscured" >>>> } , >>>> sendMetricInfo: true, >>>> alias: alias1 >>>> }; >>>> >>>> function HandleAeroGearNotification(event) { >>>> console.log(?HandleAeroGearNotification: event => ? + >>>> JSON.stringify(event)); >>>> >>>> // Stuff cut for clarity >>>> } >>>> >>>> // Slightly simplified registration event. >>>> push.register(HandleAeroGearNotification , function () { >>>> console.log(?Success?): >>>> } , function () { >>>> console.log(?Failure?); >>>> } , aeroGearPushConfig); >>>> >>>> We cannot see any reference to this issue in the JIRA database and >>>> wondered if it is a bug or not. >>>> >>>> If its a bug we are happy to raise it accordingly. >>>> >>>> Please let us know, >>>> >>>> Thanks >>>> >>>> Rob >>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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/20151216/12ccb629/attachment.html From edewit at redhat.com Wed Dec 16 11:54:08 2015 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 16 Dec 2015 17:54:08 +0100 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: <783F9E55-54CC-4C9E-857F-64A03DB1BC96@robertwillett.com> References: <783F9E55-54CC-4C9E-857F-64A03DB1BC96@robertwillett.com> Message-ID: Hi Rob, What you could try is to debug this in xcode, when the notification is touched it should launch the app and that will in turn call the JS callback. Would be good to see if this code is called 100% of the time. You can put a breakpoint here: https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56 That code will execute on cold start and here: https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102 That is where the onNotification callback gets invoked. Hope this helps, On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett wrote: > Sebastien > > Yes, we do it at that point, $ionicPlatform.ready. I include the whole of > that area of code for reference but we?re not expecting you to debug it for > us. Merely to demonstrate its there. > > At the moment all we want the code to do is put an alert up. > > .run(function($ionicPlatform , CordovaService) { > $ionicPlatform.ready(function() { > if (window.StatusBar) { > // org.apache.cordova.statusbar required > StatusBar.styleDefault(); > } > > ConsoleLog('<<< Cordova ready >>>'); > > /* This seems to remove an annoying page flicker on iOS when the keyboard is displayed */ > cordova.plugins.Keyboard.disableScroll(true); > > isDeviceReady = true; > > var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app"; > > var aeroGearPushConfig = { > pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", > ios: { > variantID: ?XXXXX?, > variantSecret: ?YYYYYYY? > } , > // sendMetricInfo: true, > alias: uuid > }; > > push.register(function (event) { > alert("EVENT = " + JSON.stringify(event)); > > } , function () { > if (1) > { > // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid)); > // ConsoleLog("UUID = " + uuid); > } > } , function () { > } , aeroGearPushConfig); > > We were still loading up another 18,000 lines of code so we need to start > pruning that back until we have something that works. > > Rob > > On 16 Dec 2015, at 16:04, Sebastien Blanc wrote: > > In the ionic app when do you do the registration of UPS ? on the > platformReady event ? > > On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett < > rob.aerogear at robertwillett.com > > wrote: > > Erik, > > We have built the simplest possible app we can that uses the Aerogear > push plugin but using the ionic tabs starter kit. > > http://ionicframework.com/getting-started/ > > We have taken the code directly from the Cordova simple app that we have > got working and put it into the Ionic app. > > if we follow your tests as below: > > 1. > > IOS App in foreground, we send a simple push notification from the > Aerogear console - Works OK, We can see the event. Good > 2. > > IOS App in background, we send a simple push notification from the > Aerogear console - Works OK, We can see the event. Good > 3. > > IOS App killed, we send a simple push notification from the Aerogear > > console and some of the time when we click on the notification in the > notification drawer we do NOT get the notification handler called. Not > so good > > > However it does appear to work most of the time with our minimal Ionic > app, but some of the time it fails. We had a run of 1 in 2 failures when > we click on the notification. Now we have just done 20 runs in a row, > each time killing the app after receiving the notification and not a > single failure. Nothing changed. > > We cannot find any obvious reason for this so we are still > investigating. > > We have reconfigured our main app to work the same way as the minimal > app but we are still getting the same issues as before, we can see the > notification in the drawer but clicking on it does NOT call the same > handler with the same code as the minimal app. We get zero calls to the > notification event handler. > > We are wondering if there is a timing issue somewhere in our code, but > we can?t see it. We also wondered if the size of the code we are > loading is the cause of a timing issue as well. > > Is there any way of adding more debugging into the Aerogear push plugin > to see if we can track things down that way? > > Its very frustrating, but thanks for your help to date. It does look > like its an interaction with our code, Ionic and the Aerogear plugin. My > money is on our code though. We?ll now start pulling working code out > of our app until we get back to the minimal app. Only 18,604 lines to go > :) > > Rob > > On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote: > > Hi Rob, > > That would be a bug, although I can not reproduce it, to test it this > is > what I've done to test it: > $ > cordova create push-test > $ > cordova platform add ios > $ > cordova plugin add aerogear-cordova-push > > copy paste your js code into www/js/index.js onDeviceReady, changed > pushServerUrl and variant info and changed quotes to " (this is your > email > client no doubt) and changed : into ; after console.log("Success") > > Attach Safari debugger and send a message when the app is in the > foreground > and get in the console: > > HandleAeroGearNotification: event => > > > {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > I press the home button and send the app to the background send > another > message and 'touch' the message to launch the app: > > HandleAeroGearNotification: event => > > > {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} > > The I kill the app by pressing home twice and swiping over the app to > remove it send another message and 'touch' it to launch the app. This > kills > my safari debugger so no way to see the console log, but in this case > coldstart should be true. To test this better changed the code to > alert > instead of console: > > function HandleAeroGearNotification(event) { > alert("HandleAeroGearNotification: event => " + event.coldstart); > > // Stuff cut for clarity > } > > I send another notification 'touch' it to launch the app and see the > alert > box display the text: > > HandleAeroGearNotification: event => true > > Hope this helps > > On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < > rob.aerogear at robertwillett.com> wrote: > > Hi, > > We think we have found a possible bug in the Aerogear Cordova 2.0.4 > push > plugin specifically on the iOS side. > Summary > > We have two versions of our app, an Android and an IOS version. Both > use > the latest Cordova push plugin 2.0.4. They also both have the latest > Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android > versions are compiled at the same time. We are running cordova 5.3.3 > with > Ionic 1.7.8 (?). > > 1. > > We make sure that both apps are NOT started up on each device. We > also > check they are NOT in the background. > 2. > > We send the same simple notification to each device. This > notification > config is as below, we have anonymised the variants and alias in this > JSON > structure, though we can report that the UPS server sends the data > correctly. We use the additionalData flag to provide the information > necessary to decide which notification has been clicked in the > notification > drawer. > > 'variants' => [?variant1?,?variant2? ], > 'message' => { > 'additionalData' => { 'Disruption_Id' => '107546', > 'EpochTime' => '1450125268' > }, > 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of > King William Street - To facilitate a heavy lift in Cannon Street, > Cannon Street will be closed. Traffic is slow moving on diversion.' > }, > 'alias' => [ ?alias1? ], > 'ttl' => 600 > }; > > 1. > > Both devices show the message, the Android device stacks the message > and the iOS device display an individual message. This looks correct. > 2. > > Clicking on the Android stacked message starts up the app and the > Javascript notification handler we have defined, > HandleAeroGearNotification > is called > > HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) > (All Directions) at the junction of King William Street - To > facilitate a heavy lift in Cannon Street, Cannon Street will be > closed. Traffic is slow moving on > > diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon > > Street (EC4N) (All Directions) at the junction of King William Street > - To facilitate a heavy lift in Cannon Street, Cannon Street will be > closed. Traffic is slow moving on diversion.","badge":"-1"}} > > 1. > > Clicking on the notification in the notification drawer on the iOS > device also starts our app up correctly but the notification handler, > HandleAeroGearNotification(), is NOT called. The app starts up as > normal as > if the notification had not been clicked. We would expect the > notification > handler to be called in iOS as it is in Android. > 2. > > All notifications are cleared on both Android and iOS correctly when > the app is started up. > 3. > > We define HandleAeroGearNotification as > > var aeroGearPushConfig = { > pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", > ios: { > variantID: ?variantid_obscured?, > variantSecret: ?variant_secret_obscured? > } , > android: { > senderID: "variantid_obscured" , > variantID: "variant_id_obscured" , > variantSecret: "variant_secret_obscured" > } , > sendMetricInfo: true, > alias: alias1 > }; > > function HandleAeroGearNotification(event) { > console.log(?HandleAeroGearNotification: event => ? + > JSON.stringify(event)); > > // Stuff cut for clarity > } > > // Slightly simplified registration event. > push.register(HandleAeroGearNotification , function () { > console.log(?Success?): > } , function () { > console.log(?Failure?); > } , aeroGearPushConfig); > > We cannot see any reference to this issue in the JIRA database and > wondered if it is a bug or not. > > If its a bug we are happy to raise it accordingly. > > Please let us know, > > Thanks > > Rob > ------------------------------ > > 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 > > ------------------------------ > > 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 > > -- Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151216/bf939bfe/attachment-0001.html From marius.schellenberger at petafuel.de Mon Dec 14 10:48:07 2015 From: marius.schellenberger at petafuel.de (Marius Schellenberger) Date: Mon, 14 Dec 2015 15:48:07 +0000 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 Message-ID: <4DF9C801E930464B8345609FA14E8A3C242BA86D@MAIL2010.petafuel.intern> Hello AeroGear dev's, I'm currently evaluating the AeroGear Unified Push Server in a pre-production environment (RedHat JBoss EAP 6.4.4) and I'm facing an issue with an idle database transaction, which is executed every time the app is deployed (or the JBoss Server is started). I'm using Postgresql 9.3 as the database backend. The idle process listed in ps aux: postgres: keycloak keycloak 10.0.6.106(55387) idle in transaction The transaction seems to hang at this SQL statement: select authentica0_.REALM_ID as REALM_ID4_28_1_, authentica0_.ID as ID1_3_1_, authentica0_.ID as ID1_3_0_, authentica0_.ALIAS as ALIAS2_3_0_, authentica0_.PROVIDER_ID as PROVIDER3_3_0_, authentica0_.REALM_ID as REALM_ID4_3_0_ from AUTHENTICATOR authentica0_ where authentica0_.REALM_ID=$1 The query results nothing, as you can see below: select * from AUTHENTICATOR; id | alias | realm_id | provider_id ----+-------+----------+------------- (0 rows) Can you guys please help me identifying this issue? Kind regards, Marius Schellenberger -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151214/e5dca3b3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5073 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-users/attachments/20151214/e5dca3b3/attachment.bin From matzew at apache.org Thu Dec 17 05:05:47 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Dec 2015 11:05:47 +0100 Subject: [Aerogear-users] Duplicated notifications In-Reply-To: <56697CCA.3090006@udl.cat> References: <56697CCA.3090006@udl.cat> Message-ID: Hi Alex, sorry for the late reply, can you file a JIRA for AGCORDOVA ? On Thu, Dec 10, 2015 at 2:23 PM, Alex Ballest? wrote: > Hi, recently I've updated to 2.0.4 cordova plugin and I noticed that lot > of times notifications are not displayed. Others the notifications are > displayed multiple times in the bar but it was only sent once, and others > times are shown with some older that I've already received. Any suggestion > to find what's happening? > > Things already detected: If APP is closed I've see the notification with > "1" number. If opened I see it with an "8" . > > Screenshots: > > http://ibin.co/2PTCBCRewjEx > http://ibin.co/2PTCPYtIqiJy > > Following the stacktrace of the last message sent: > http://pastebin.com/FtFr6fbc > > Thanks > > Alex. > > -- > > 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 > > > _______________________________________________ > 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/20151217/8bc2e6a9/attachment.html From matzew at apache.org Thu Dec 17 05:10:56 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Dec 2015 11:10:56 +0100 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 In-Reply-To: <4DF9C801E930464B8345609FA14E8A3C242BA86D@MAIL2010.petafuel.intern> References: <4DF9C801E930464B8345609FA14E8A3C242BA86D@MAIL2010.petafuel.intern> Message-ID: Hello Marius, sorry for the late reply - your mail was stuck in the moderators queue. Did you subscribe before sending? Anyways. I am not sure about this issue, looks like there is a bug in the "old" Keycloak we use, on 1.1.0 of UPS. We are in the process of updating it to a more recent version of Keycloak (1.7.0): https://github.com/aerogear/aerogear-unifiedpush-server/pull/659 Can you file a JIRA against Keycloak -> http://JIRA.jboss.org/browse/KEYCLOAK We have done a bit of testing w/ UPS 1.1.0 and Postgres9 - but I am, tbh, not sure if we did test w/ 9.3 :/ I will create docker-compose files, that will use this DB for our own testing of UPS. I will share my evaluations of this later (today/tomorow) Sorry for the inconvenience! HTH, Matthias On Mon, Dec 14, 2015 at 4:48 PM, Marius Schellenberger < marius.schellenberger at petafuel.de> wrote: > Hello AeroGear dev?s, > > > > I?m currently evaluating the AeroGear Unified Push Server in a > pre-production environment (RedHat JBoss EAP 6.4.4) and I?m facing an issue > with an idle database transaction, which is executed every time the app is > deployed (or the JBoss Server is started). > > > > I?m using Postgresql 9.3 as the database backend. > > > > The idle process listed in ps aux: > > postgres: keycloak keycloak 10.0.6.106(55387) idle in transaction > > > > The transaction seems to hang at this SQL statement: > > select authentica0_.REALM_ID as REALM_ID4_28_1_, authentica0_.ID as > ID1_3_1_, authentica0_.ID as ID1_3_0_, authentica0_.ALIAS as ALIAS2_3_0_, > authentica0_.PROVIDER_ID as PROVIDER3_3_0_, authentica0_.REALM_ID as > REALM_ID4_3_0_ from AUTHENTICATOR authentica0_ where > authentica0_.REALM_ID=$1 > > > > The query results nothing, as you can see below: > > select * from AUTHENTICATOR; > > id | alias | realm_id | provider_id > > ----+-------+----------+------------- > > (0 rows) > > > > Can you guys please help me identifying this issue? > > > > Kind regards, > > > > Marius Schellenberger > > > > _______________________________________________ > 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/20151217/39bc0642/attachment-0001.html From matzew at apache.org Thu Dec 17 12:47:13 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Dec 2015 18:47:13 +0100 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 In-Reply-To: References: <4DF9C801E930464B8345609FA14E8A3C242BA86D@MAIL2010.petafuel.intern> Message-ID: Hello Marius, regarding your transaction code, I filed this ticket: https://issues.jboss.org/browse/KEYCLOAK-2235 Didn't get to do some docker/postgres 9.3 tests But for my shell history, I was using 9.3 - but not sure if w/ EAP (6.3.x / 6.4.1) or WildFly More on Doccker tomorrow On Thu, Dec 17, 2015 at 11:10 AM, Matthias Wessendorf wrote: > Hello Marius, > > sorry for the late reply - your mail was stuck in the moderators queue. > Did you subscribe before sending? Anyways. > > I am not sure about this issue, looks like there is a bug in the "old" > Keycloak we use, on 1.1.0 of UPS. > We are in the process of updating it to a more recent version of Keycloak > (1.7.0): > https://github.com/aerogear/aerogear-unifiedpush-server/pull/659 > > Can you file a JIRA against Keycloak -> > http://JIRA.jboss.org/browse/KEYCLOAK > > We have done a bit of testing w/ UPS 1.1.0 and Postgres9 - but I am, tbh, > not sure if we did test w/ 9.3 :/ > > I will create docker-compose files, that will use this DB for our own > testing of UPS. I will share my evaluations of this later (today/tomorow) > > Sorry for the inconvenience! > > HTH, > Matthias > > On Mon, Dec 14, 2015 at 4:48 PM, Marius Schellenberger < > marius.schellenberger at petafuel.de> wrote: > >> Hello AeroGear dev?s, >> >> >> >> I?m currently evaluating the AeroGear Unified Push Server in a >> pre-production environment (RedHat JBoss EAP 6.4.4) and I?m facing an issue >> with an idle database transaction, which is executed every time the app is >> deployed (or the JBoss Server is started). >> >> >> >> I?m using Postgresql 9.3 as the database backend. >> >> >> >> The idle process listed in ps aux: >> >> postgres: keycloak keycloak 10.0.6.106(55387) idle in transaction >> >> >> >> The transaction seems to hang at this SQL statement: >> >> select authentica0_.REALM_ID as REALM_ID4_28_1_, authentica0_.ID as >> ID1_3_1_, authentica0_.ID as ID1_3_0_, authentica0_.ALIAS as ALIAS2_3_0_, >> authentica0_.PROVIDER_ID as PROVIDER3_3_0_, authentica0_.REALM_ID as >> REALM_ID4_3_0_ from AUTHENTICATOR authentica0_ where >> authentica0_.REALM_ID=$1 >> >> >> >> The query results nothing, as you can see below: >> >> select * from AUTHENTICATOR; >> >> id | alias | realm_id | provider_id >> >> ----+-------+----------+------------- >> >> (0 rows) >> >> >> >> Can you guys please help me identifying this issue? >> >> >> >> Kind regards, >> >> >> >> Marius Schellenberger >> >> >> >> _______________________________________________ >> 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/20151217/3bb7b112/attachment.html From rob.aerogear at robertwillett.com Fri Dec 18 12:26:15 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Fri, 18 Dec 2015 17:26:15 +0000 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: References: <783F9E55-54CC-4C9E-857F-64A03DB1BC96@robertwillett.com> Message-ID: <23B53EED-5498-4209-A3D3-D6EB9F221B2A@robertwillett.com> Erok, We?ve not forgotten the notification issue, we?re still working on it to try and get to the bottom of it. The problem for us is that its not so simple to cut code out and try and reduce the problem down. Our code is quite interlinked, for good or for worse. We?ve added some simple sound debugging to the Objective C source for the Aerogear plugin. This means that we can hear where things are when the plugin starts up from a cold start after receiving a notification. This works quite well. We initially added a beep to here ``` - (void)notificationReceived { NSLog(@"Notification received"); AudioServicesPlaySystemSound(1005); if (notificationMessage && self.callbackId) { ``` and this works whenever we get a notification in the foreground and when the app is in the background. We then started tracing backwards in the source code to see what called notificationReceived We can see it here ``` - (void)register:(CDVInvokedUrlCommand *)command; { NSLog(@"register"); self.callbackId = command.callbackId; AudioServicesPlaySystemSound(1007); isInline = NO; [self.commandDelegate runInBackground:^{ NSMutableDictionary *options = [self parseOptions:command]; [self saveConfig:options]; // when running under iOS 8 we will use the new API for APNS registration #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000 if ([[UIApplication sharedApplication] respondsToSelector:@selector(registerUserNotificationSettings:)]) { UIUserNotificationSettings* notificationSettings = [UIUserNotificationSettings settingsForTypes:UIUserNotificationTypeAlert | UIUserNotificationTypeBadge | UIUserNotificationTypeSound categories:nil]; [[UIApplication sharedApplication] registerUserNotificationSettings:notificationSettings]; [[UIApplication sharedApplication] registerForRemoteNotifications]; } else { [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)]; } #else [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)]; #endif CDVPluginResult* pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_NO_RESULT]; [pluginResult setKeepCallback:@YES]; [self.commandDelegate sendPluginResult:pluginResult callbackId:command.callbackId]; }]; if (notificationMessage) // if there is a pending startup notification { AudioServicesPlaySystemSound(1024); [self notificationReceived]; // go ahead and process it } } ```` So we add some more beeps in to track down whats going on. We add AudioServicesPlaySystemSound(1007) at the beginning of the function and add AudioServicesPlaySystemSound(1024) just before we call the notificationReceived method. We get the first sounds on startup but do NOT get the second set of sounds. It looks like notificationMessage is not being set at application startup. Our problem now is that we are not Objective-C developers so we are struggling to debug much further. So trying to understand how notificationMessage is set and defined as its declared as @synthesis is unclear. We?ll start reading and learning quickly but as this is new for us, so we will be slow. Any suggestions welcomed, Rob On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote: > Hi Rob, > > What you could try is to debug this in xcode, when the notification is > touched it should launch the app and that will in turn call the JS > callback. Would be good to see if this code is called 100% of the > time. > > You can put a breakpoint here: > https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56 > > That code will execute on cold start and here: > https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102 > > That is where the onNotification callback gets invoked. > > Hope this helps, > > On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett > > wrote: > >> Sebastien >> >> Yes, we do it at that point, $ionicPlatform.ready. I include the >> whole of >> that area of code for reference but we?re not expecting you to >> debug it for >> us. Merely to demonstrate its there. >> >> At the moment all we want the code to do is put an alert up. >> >> .run(function($ionicPlatform , CordovaService) { >> $ionicPlatform.ready(function() { >> if (window.StatusBar) { >> // org.apache.cordova.statusbar required >> StatusBar.styleDefault(); >> } >> >> ConsoleLog('<<< Cordova ready >>>'); >> >> /* This seems to remove an annoying page flicker on iOS when the >> keyboard is displayed */ >> cordova.plugins.Keyboard.disableScroll(true); >> >> isDeviceReady = true; >> >> var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app"; >> >> var aeroGearPushConfig = { >> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >> ios: { >> variantID: ?XXXXX?, >> variantSecret: ?YYYYYYY? >> } , >> // sendMetricInfo: true, >> alias: uuid >> }; >> >> push.register(function (event) { >> alert("EVENT = " + JSON.stringify(event)); >> >> } , function () { >> if (1) >> { >> // alert("AeroGearSuccessHandler: OK " + >> JSON.stringify(uuid)); >> // ConsoleLog("UUID = " + uuid); >> } >> } , function () { >> } , aeroGearPushConfig); >> >> We were still loading up another 18,000 lines of code so we need to >> start >> pruning that back until we have something that works. >> >> Rob >> >> On 16 Dec 2015, at 16:04, Sebastien Blanc wrote: >> >> In the ionic app when do you do the registration of UPS ? on the >> platformReady event ? >> >> On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett < >> rob.aerogear at robertwillett.com >> >> wrote: >> >> Erik, >> >> We have built the simplest possible app we can that uses the Aerogear >> push plugin but using the ionic tabs starter kit. >> >> http://ionicframework.com/getting-started/ >> >> We have taken the code directly from the Cordova simple app that we >> have >> got working and put it into the Ionic app. >> >> if we follow your tests as below: >> >> 1. >> >> IOS App in foreground, we send a simple push notification from the >> Aerogear console - Works OK, We can see the event. Good >> 2. >> >> IOS App in background, we send a simple push notification from the >> Aerogear console - Works OK, We can see the event. Good >> 3. >> >> IOS App killed, we send a simple push notification from the Aerogear >> >> console and some of the time when we click on the notification in the >> notification drawer we do NOT get the notification handler called. >> Not >> so good >> >> >> However it does appear to work most of the time with our minimal >> Ionic >> app, but some of the time it fails. We had a run of 1 in 2 failures >> when >> we click on the notification. Now we have just done 20 runs in a row, >> each time killing the app after receiving the notification and not a >> single failure. Nothing changed. >> >> We cannot find any obvious reason for this so we are still >> investigating. >> >> We have reconfigured our main app to work the same way as the minimal >> app but we are still getting the same issues as before, we can see >> the >> notification in the drawer but clicking on it does NOT call the same >> handler with the same code as the minimal app. We get zero calls to >> the >> notification event handler. >> >> We are wondering if there is a timing issue somewhere in our code, >> but >> we can?t see it. We also wondered if the size of the code we are >> loading is the cause of a timing issue as well. >> >> Is there any way of adding more debugging into the Aerogear push >> plugin >> to see if we can track things down that way? >> >> Its very frustrating, but thanks for your help to date. It does look >> like its an interaction with our code, Ionic and the Aerogear plugin. >> My >> money is on our code though. We?ll now start pulling working code >> out >> of our app until we get back to the minimal app. Only 18,604 lines to >> go >> :) >> >> Rob >> >> On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote: >> >> Hi Rob, >> >> That would be a bug, although I can not reproduce it, to test it this >> is >> what I've done to test it: >> $ > cordova create push-test >> $ > cordova platform add ios >> $ > cordova plugin add aerogear-cordova-push >> >> copy paste your js code into www/js/index.js onDeviceReady, changed >> pushServerUrl and variant info and changed quotes to " (this is your >> email >> client no doubt) and changed : into ; after console.log("Success") >> >> Attach Safari debugger and send a message when the app is in the >> foreground >> and get in the console: >> >> HandleAeroGearNotification: event => >> >> >> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} >> >> I press the home button and send the app to the background send >> another >> message and 'touch' the message to launch the app: >> >> HandleAeroGearNotification: event => >> >> >> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} >> >> The I kill the app by pressing home twice and swiping over the app to >> remove it send another message and 'touch' it to launch the app. This >> kills >> my safari debugger so no way to see the console log, but in this case >> coldstart should be true. To test this better changed the code to >> alert >> instead of console: >> >> function HandleAeroGearNotification(event) { >> alert("HandleAeroGearNotification: event => " + event.coldstart); >> >> // Stuff cut for clarity >> } >> >> I send another notification 'touch' it to launch the app and see the >> alert >> box display the text: >> >> HandleAeroGearNotification: event => true >> >> Hope this helps >> >> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < >> rob.aerogear at robertwillett.com> wrote: >> >> Hi, >> >> We think we have found a possible bug in the Aerogear Cordova 2.0.4 >> push >> plugin specifically on the iOS side. >> Summary >> >> We have two versions of our app, an Android and an IOS version. Both >> use >> the latest Cordova push plugin 2.0.4. They also both have the latest >> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android >> versions are compiled at the same time. We are running cordova 5.3.3 >> with >> Ionic 1.7.8 (?). >> >> 1. >> >> We make sure that both apps are NOT started up on each device. We >> also >> check they are NOT in the background. >> 2. >> >> We send the same simple notification to each device. This >> notification >> config is as below, we have anonymised the variants and alias in this >> JSON >> structure, though we can report that the UPS server sends the data >> correctly. We use the additionalData flag to provide the information >> necessary to decide which notification has been clicked in the >> notification >> drawer. >> >> 'variants' => [?variant1?,?variant2? ], >> 'message' => { >> 'additionalData' => { 'Disruption_Id' => '107546', >> 'EpochTime' => '1450125268' >> }, >> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of >> King William Street - To facilitate a heavy lift in Cannon Street, >> Cannon Street will be closed. Traffic is slow moving on diversion.' >> }, >> 'alias' => [ ?alias1? ], >> 'ttl' => 600 >> }; >> >> 1. >> >> Both devices show the message, the Android device stacks the message >> and the iOS device display an individual message. This looks correct. >> 2. >> >> Clicking on the Android stacked message starts up the app and the >> Javascript notification handler we have defined, >> HandleAeroGearNotification >> is called >> >> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) >> (All Directions) at the junction of King William Street - To >> facilitate a heavy lift in Cannon Street, Cannon Street will be >> closed. Traffic is slow moving on >> >> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon >> >> Street (EC4N) (All Directions) at the junction of King William Street >> - To facilitate a heavy lift in Cannon Street, Cannon Street will be >> closed. Traffic is slow moving on diversion.","badge":"-1"}} >> >> 1. >> >> Clicking on the notification in the notification drawer on the iOS >> device also starts our app up correctly but the notification handler, >> HandleAeroGearNotification(), is NOT called. The app starts up as >> normal as >> if the notification had not been clicked. We would expect the >> notification >> handler to be called in iOS as it is in Android. >> 2. >> >> All notifications are cleared on both Android and iOS correctly when >> the app is started up. >> 3. >> >> We define HandleAeroGearNotification as >> >> var aeroGearPushConfig = { >> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >> ios: { >> variantID: ?variantid_obscured?, >> variantSecret: ?variant_secret_obscured? >> } , >> android: { >> senderID: "variantid_obscured" , >> variantID: "variant_id_obscured" , >> variantSecret: "variant_secret_obscured" >> } , >> sendMetricInfo: true, >> alias: alias1 >> }; >> >> function HandleAeroGearNotification(event) { >> console.log(?HandleAeroGearNotification: event => ? + >> JSON.stringify(event)); >> >> // Stuff cut for clarity >> } >> >> // Slightly simplified registration event. >> push.register(HandleAeroGearNotification , function () { >> console.log(?Success?): >> } , function () { >> console.log(?Failure?); >> } , aeroGearPushConfig); >> >> We cannot see any reference to this issue in the JIRA database and >> wondered if it is a bug or not. >> >> If its a bug we are happy to raise it accordingly. >> >> Please let us know, >> >> Thanks >> >> Rob >> ------------------------------ >> >> 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 >> >> ------------------------------ >> >> 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 >> >> > > > -- > 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/20151218/473f8046/attachment-0001.html From rob.aerogear at robertwillett.com Sun Dec 20 14:26:33 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Sun, 20 Dec 2015 19:26:33 +0000 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: <23B53EED-5498-4209-A3D3-D6EB9F221B2A@robertwillett.com> References: <783F9E55-54CC-4C9E-857F-64A03DB1BC96@robertwillett.com> <23B53EED-5498-4209-A3D3-D6EB9F221B2A@robertwillett.com> Message-ID: Erik, Sebastien, We?ve spent a significant part of the weekend looking into this issue and we have still not got to the bottom of it. We have built a very simple Ionic test app that works in isolation. We have used the default Ionic tabs at http://ionicframework.com/getting-started/ We then add in our Javascript files as ``` We do NOT call any functions within any of these files, indeed we make no reference to these files beyond including them in the index.html file. Our dummy html templates make no reference to them. We simply load the javascript files in. We get no errors from including the files. We have used the controllers and services as provided by the dummy sample Ionic app. If we then send foreground notifications, the notifications are always handled by the Aerogear notification handler. If we send notifications to the app when it is in the background, the notifications are always handled by the Aerogear notification handler. If we kill by swiping up the app, we get the notifications but when we click on the notification from the main IOS screen it is arbitrary as to whether the notification is handled by the Aerogear handler when the app starts up. Sometimes the handler is called, but once the handler is not called, the Aerogear notification handler never appears to be called again. If we reinstall the app it sometimes works again and sometimes it fails. We can reinstall the app and the Aerogear notification handler might be called or it might not. We just ran the app with 20 tests to the app, each time killing the app and then sending down a a notification and it started the Aerogear notification handler each time. We then reinstall the app again, no changes in the code and it simply doesn?t process any notification when the app is closed. The notification turns up, but no event is called to the Aerogear event handler. Given that we are getting arbitrary results from the same codebase, clearly something is remiss. Sometimes it works and sometimes it doesn?t. There is no logic that we can see. We?ve closed down Xcode after installing, we?ve started and stopped our sample app a few times to try and make sure its closed down, ew are sending exactly the same payload each time. We feel that there is some sort of timing or race condition, or if this was a piece of C code, that we are overwriting somewhere we shouldn?t be. It has that sort of feeling of a pointer going bad but we cannot see where the issue is at all. The fact that we get different results from doing the same install is very worrying but we can?t say whether its the Aerogear plugin, Ionic or our code. Thanks, Rob On 18 Dec 2015, at 17:26, Rob Willett wrote: > Erok, > > We?ve not forgotten the notification issue, we?re still working on > it to try and get to the bottom of it. The problem for us is that its > not so simple to cut code out and try and reduce the problem down. Our > code is quite interlinked, for good or for worse. > > We?ve added some simple sound debugging to the Objective C source > for the Aerogear plugin. This means that we can hear where things are > when the plugin starts up from a cold start after receiving a > notification. This works quite well. > > We initially added a beep to here > > ``` > - (void)notificationReceived { > NSLog(@"Notification received"); > > AudioServicesPlaySystemSound(1005); > > > if (notificationMessage && self.callbackId) { > ``` > > and this works whenever we get a notification in the foreground and > when the app is in the background. We then started tracing backwards > in the source code to see what called notificationReceived > > We can see it here > > ``` > - (void)register:(CDVInvokedUrlCommand *)command; { > NSLog(@"register"); > self.callbackId = command.callbackId; > > AudioServicesPlaySystemSound(1007); > > isInline = NO; > > [self.commandDelegate runInBackground:^{ > NSMutableDictionary *options = [self parseOptions:command]; > [self saveConfig:options]; > > // when running under iOS 8 we will use the new API for APNS > registration > #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000 > if ([[UIApplication sharedApplication] > respondsToSelector:@selector(registerUserNotificationSettings:)]) { > UIUserNotificationSettings* notificationSettings = > [UIUserNotificationSettings > settingsForTypes:UIUserNotificationTypeAlert | > UIUserNotificationTypeBadge | UIUserNotificationTypeSound > categories:nil]; > [[UIApplication sharedApplication] > registerUserNotificationSettings:notificationSettings]; > [[UIApplication sharedApplication] > registerForRemoteNotifications]; > } else { > [[UIApplication sharedApplication] > registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | > UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)]; > } > > #else > [[UIApplication sharedApplication] > registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | > UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)]; > #endif > > CDVPluginResult* pluginResult = [CDVPluginResult > resultWithStatus:CDVCommandStatus_NO_RESULT]; > [pluginResult setKeepCallback:@YES]; > [self.commandDelegate sendPluginResult:pluginResult > callbackId:command.callbackId]; > }]; > > if (notificationMessage) // if there is a pending startup > notification > { > AudioServicesPlaySystemSound(1024); > > [self notificationReceived]; // go ahead and process it > } > } > ```` > > So we add some more beeps in to track down whats going on. We add > AudioServicesPlaySystemSound(1007) at the beginning of the function > and add AudioServicesPlaySystemSound(1024) just before we call the > notificationReceived method. > > We get the first sounds on startup but do NOT get the second set of > sounds. It looks like notificationMessage is not being set at > application startup. > > Our problem now is that we are not Objective-C developers so we are > struggling to debug much further. So trying to understand how > notificationMessage is set and defined as its declared as @synthesis > is unclear. We?ll start reading and learning quickly but as this is > new for us, so we will be slow. > > Any suggestions welcomed, > > Rob > > On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote: > >> Hi Rob, >> >> What you could try is to debug this in xcode, when the notification >> is >> touched it should launch the app and that will in turn call the JS >> callback. Would be good to see if this code is called 100% of the >> time. >> >> You can put a breakpoint here: >> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56 >> >> That code will execute on cold start and here: >> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102 >> >> That is where the onNotification callback gets invoked. >> >> Hope this helps, >> >> On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett >> >> wrote: >> >>> Sebastien >>> >>> Yes, we do it at that point, $ionicPlatform.ready. I include the >>> whole of >>> that area of code for reference but we?re not expecting you to >>> debug it for >>> us. Merely to demonstrate its there. >>> >>> At the moment all we want the code to do is put an alert up. >>> >>> .run(function($ionicPlatform , CordovaService) { >>> $ionicPlatform.ready(function() { >>> if (window.StatusBar) { >>> // org.apache.cordova.statusbar required >>> StatusBar.styleDefault(); >>> } >>> >>> ConsoleLog('<<< Cordova ready >>>'); >>> >>> /* This seems to remove an annoying page flicker on iOS when the >>> keyboard is displayed */ >>> cordova.plugins.Keyboard.disableScroll(true); >>> >>> isDeviceReady = true; >>> >>> var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app"; >>> >>> var aeroGearPushConfig = { >>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >>> ios: { >>> variantID: ?XXXXX?, >>> variantSecret: ?YYYYYYY? >>> } , >>> // sendMetricInfo: true, >>> alias: uuid >>> }; >>> >>> push.register(function (event) { >>> alert("EVENT = " + JSON.stringify(event)); >>> >>> } , function () { >>> if (1) >>> { >>> // alert("AeroGearSuccessHandler: OK " + >>> JSON.stringify(uuid)); >>> // ConsoleLog("UUID = " + uuid); >>> } >>> } , function () { >>> } , aeroGearPushConfig); >>> >>> We were still loading up another 18,000 lines of code so we need to >>> start >>> pruning that back until we have something that works. >>> >>> Rob >>> >>> On 16 Dec 2015, at 16:04, Sebastien Blanc wrote: >>> >>> In the ionic app when do you do the registration of UPS ? on the >>> platformReady event ? >>> >>> On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett < >>> rob.aerogear at robertwillett.com >>> >>> wrote: >>> >>> Erik, >>> >>> We have built the simplest possible app we can that uses the >>> Aerogear >>> push plugin but using the ionic tabs starter kit. >>> >>> http://ionicframework.com/getting-started/ >>> >>> We have taken the code directly from the Cordova simple app that we >>> have >>> got working and put it into the Ionic app. >>> >>> if we follow your tests as below: >>> >>> 1. >>> >>> IOS App in foreground, we send a simple push notification from the >>> Aerogear console - Works OK, We can see the event. Good >>> 2. >>> >>> IOS App in background, we send a simple push notification from the >>> Aerogear console - Works OK, We can see the event. Good >>> 3. >>> >>> IOS App killed, we send a simple push notification from the Aerogear >>> >>> console and some of the time when we click on the notification in >>> the >>> notification drawer we do NOT get the notification handler called. >>> Not >>> so good >>> >>> >>> However it does appear to work most of the time with our minimal >>> Ionic >>> app, but some of the time it fails. We had a run of 1 in 2 failures >>> when >>> we click on the notification. Now we have just done 20 runs in a >>> row, >>> each time killing the app after receiving the notification and not a >>> single failure. Nothing changed. >>> >>> We cannot find any obvious reason for this so we are still >>> investigating. >>> >>> We have reconfigured our main app to work the same way as the >>> minimal >>> app but we are still getting the same issues as before, we can see >>> the >>> notification in the drawer but clicking on it does NOT call the same >>> handler with the same code as the minimal app. We get zero calls to >>> the >>> notification event handler. >>> >>> We are wondering if there is a timing issue somewhere in our code, >>> but >>> we can?t see it. We also wondered if the size of the code we are >>> loading is the cause of a timing issue as well. >>> >>> Is there any way of adding more debugging into the Aerogear push >>> plugin >>> to see if we can track things down that way? >>> >>> Its very frustrating, but thanks for your help to date. It does look >>> like its an interaction with our code, Ionic and the Aerogear >>> plugin. My >>> money is on our code though. We?ll now start pulling working code >>> out >>> of our app until we get back to the minimal app. Only 18,604 lines >>> to go >>> :) >>> >>> Rob >>> >>> On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote: >>> >>> Hi Rob, >>> >>> That would be a bug, although I can not reproduce it, to test it >>> this >>> is >>> what I've done to test it: >>> $ > cordova create push-test >>> $ > cordova platform add ios >>> $ > cordova plugin add aerogear-cordova-push >>> >>> copy paste your js code into www/js/index.js onDeviceReady, changed >>> pushServerUrl and variant info and changed quotes to " (this is your >>> email >>> client no doubt) and changed : into ; after console.log("Success") >>> >>> Attach Safari debugger and send a message when the app is in the >>> foreground >>> and get in the console: >>> >>> HandleAeroGearNotification: event => >>> >>> >>> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} >>> >>> I press the home button and send the app to the background send >>> another >>> message and 'touch' the message to launch the app: >>> >>> HandleAeroGearNotification: event => >>> >>> >>> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} >>> >>> The I kill the app by pressing home twice and swiping over the app >>> to >>> remove it send another message and 'touch' it to launch the app. >>> This >>> kills >>> my safari debugger so no way to see the console log, but in this >>> case >>> coldstart should be true. To test this better changed the code to >>> alert >>> instead of console: >>> >>> function HandleAeroGearNotification(event) { >>> alert("HandleAeroGearNotification: event => " + event.coldstart); >>> >>> // Stuff cut for clarity >>> } >>> >>> I send another notification 'touch' it to launch the app and see the >>> alert >>> box display the text: >>> >>> HandleAeroGearNotification: event => true >>> >>> Hope this helps >>> >>> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < >>> rob.aerogear at robertwillett.com> wrote: >>> >>> Hi, >>> >>> We think we have found a possible bug in the Aerogear Cordova 2.0.4 >>> push >>> plugin specifically on the iOS side. >>> Summary >>> >>> We have two versions of our app, an Android and an IOS version. Both >>> use >>> the latest Cordova push plugin 2.0.4. They also both have the latest >>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and >>> Android >>> versions are compiled at the same time. We are running cordova 5.3.3 >>> with >>> Ionic 1.7.8 (?). >>> >>> 1. >>> >>> We make sure that both apps are NOT started up on each device. We >>> also >>> check they are NOT in the background. >>> 2. >>> >>> We send the same simple notification to each device. This >>> notification >>> config is as below, we have anonymised the variants and alias in >>> this >>> JSON >>> structure, though we can report that the UPS server sends the data >>> correctly. We use the additionalData flag to provide the information >>> necessary to decide which notification has been clicked in the >>> notification >>> drawer. >>> >>> 'variants' => [?variant1?,?variant2? ], >>> 'message' => { >>> 'additionalData' => { 'Disruption_Id' => '107546', >>> 'EpochTime' => '1450125268' >>> }, >>> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of >>> King William Street - To facilitate a heavy lift in Cannon Street, >>> Cannon Street will be closed. Traffic is slow moving on diversion.' >>> }, >>> 'alias' => [ ?alias1? ], >>> 'ttl' => 600 >>> }; >>> >>> 1. >>> >>> Both devices show the message, the Android device stacks the message >>> and the iOS device display an individual message. This looks >>> correct. >>> 2. >>> >>> Clicking on the Android stacked message starts up the app and the >>> Javascript notification handler we have defined, >>> HandleAeroGearNotification >>> is called >>> >>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) >>> (All Directions) at the junction of King William Street - To >>> facilitate a heavy lift in Cannon Street, Cannon Street will be >>> closed. Traffic is slow moving on >>> >>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon >>> >>> Street (EC4N) (All Directions) at the junction of King William >>> Street >>> - To facilitate a heavy lift in Cannon Street, Cannon Street will be >>> closed. Traffic is slow moving on diversion.","badge":"-1"}} >>> >>> 1. >>> >>> Clicking on the notification in the notification drawer on the iOS >>> device also starts our app up correctly but the notification >>> handler, >>> HandleAeroGearNotification(), is NOT called. The app starts up as >>> normal as >>> if the notification had not been clicked. We would expect the >>> notification >>> handler to be called in iOS as it is in Android. >>> 2. >>> >>> All notifications are cleared on both Android and iOS correctly when >>> the app is started up. >>> 3. >>> >>> We define HandleAeroGearNotification as >>> >>> var aeroGearPushConfig = { >>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >>> ios: { >>> variantID: ?variantid_obscured?, >>> variantSecret: ?variant_secret_obscured? >>> } , >>> android: { >>> senderID: "variantid_obscured" , >>> variantID: "variant_id_obscured" , >>> variantSecret: "variant_secret_obscured" >>> } , >>> sendMetricInfo: true, >>> alias: alias1 >>> }; >>> >>> function HandleAeroGearNotification(event) { >>> console.log(?HandleAeroGearNotification: event => ? + >>> JSON.stringify(event)); >>> >>> // Stuff cut for clarity >>> } >>> >>> // Slightly simplified registration event. >>> push.register(HandleAeroGearNotification , function () { >>> console.log(?Success?): >>> } , function () { >>> console.log(?Failure?); >>> } , aeroGearPushConfig); >>> >>> We cannot see any reference to this issue in the JIRA database and >>> wondered if it is a bug or not. >>> >>> If its a bug we are happy to raise it accordingly. >>> >>> Please let us know, >>> >>> Thanks >>> >>> Rob >>> ------------------------------ >>> >>> 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 >>> >>> ------------------------------ >>> >>> 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 >>> >>> >> >> >> -- >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151220/addd3ca3/attachment-0001.html From rob.aerogear at robertwillett.com Sun Dec 20 14:52:29 2015 From: rob.aerogear at robertwillett.com (Rob Willett) Date: Sun, 20 Dec 2015 19:52:29 +0000 Subject: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version In-Reply-To: References: <783F9E55-54CC-4C9E-857F-64A03DB1BC96@robertwillett.com> <23B53EED-5498-4209-A3D3-D6EB9F221B2A@robertwillett.com> Message-ID: <572042FF-7B4C-4CD0-BC4D-A7057A39A191@robertwillett.com> Dear all, We *think* we can now reproduce the problem. Clearly writing the last e-mail has focussed our attention :) Summary. We have a simple Ionic app that would call the Aerogear notification handler when notifications were receive in the foreground and when the app was in the background. The Aerogear notification handler would sometimes be called and sometimes NOT be called when a notification was received when the app was not started. See our long previous e-mails detailing the problem. We think we can now reproduce the problem as follows: 1. Kill the app. 2. Send a notification down to the app. 3. It appears in the iOS notification drawer 4. Click on the notification. if the Aerogear handler has worked then go to 1 and repeat. We want a failure :) 5. If the Aerogear handler is NOT called, then put the app into the background using the Home button and then click on the app icon to resume. 6. The notification is now processed by the Aerogear handler. We can now see it. We are at a loss to explain this, we found it by accident, but we think it shows some sort of timing issue somewhere because if we pull out the various Javascript files the Aerogear plugin seems to work consistently at startup. We have checked and checked the JavaScript files and cannot see any error with them at all at load time. All suggestions welcome now. Rob On 20 Dec 2015, at 19:26, Rob Willett wrote: > Erik, Sebastien, > > We?ve spent a significant part of the weekend looking into this > issue and we have still not got to the bottom of it. > > We have built a very simple Ionic test app that works in isolation. We > have used the default Ionic tabs at > > http://ionicframework.com/getting-started/ > > We then add in our Javascript files as > > > > > > > > > > > > > > > > ``` > > We do NOT call any functions within any of these files, indeed we make > no reference to these files beyond including them in the index.html > file. Our dummy html templates make no reference to them. We simply > load the javascript files in. We get no errors from including the > files. We have used the controllers and services as provided by the > dummy sample Ionic app. > > If we then send foreground notifications, the notifications are always > handled by the Aerogear notification handler. > > If we send notifications to the app when it is in the background, the > notifications are always handled by the Aerogear notification handler. > > If we kill by swiping up the app, we get the notifications but when we > click on the notification from the main IOS screen it is arbitrary as > to whether the notification is handled by the Aerogear handler when > the app starts up. Sometimes the handler is called, but once the > handler is not called, the Aerogear notification handler never appears > to be called again. If we reinstall the app it sometimes works again > and sometimes it fails. > > We can reinstall the app and the Aerogear notification handler might > be called or it might not. We just ran the app with 20 tests to the > app, each time killing the app and then sending down a a notification > and it started the Aerogear notification handler each time. We then > reinstall the app again, no changes in the code and it simply > doesn?t process any notification when the app is closed. The > notification turns up, but no event is called to the Aerogear event > handler. > > Given that we are getting arbitrary results from the same codebase, > clearly something is remiss. Sometimes it works and sometimes it > doesn?t. There is no logic that we can see. We?ve closed down > Xcode after installing, we?ve started and stopped our sample app a > few times to try and make sure its closed down, ew are sending exactly > the same payload each time. > > We feel that there is some sort of timing or race condition, or if > this was a piece of C code, that we are overwriting somewhere we > shouldn?t be. It has that sort of feeling of a pointer going bad but > we cannot see where the issue is at all. The fact that we get > different results from doing the same install is very worrying but we > can?t say whether its the Aerogear plugin, Ionic or our code. > > Thanks, > > Rob > > > On 18 Dec 2015, at 17:26, Rob Willett wrote: > >> Erok, >> >> We?ve not forgotten the notification issue, we?re still working >> on it to try and get to the bottom of it. The problem for us is that >> its not so simple to cut code out and try and reduce the problem >> down. Our code is quite interlinked, for good or for worse. >> >> We?ve added some simple sound debugging to the Objective C source >> for the Aerogear plugin. This means that we can hear where things are >> when the plugin starts up from a cold start after receiving a >> notification. This works quite well. >> >> We initially added a beep to here >> >> ``` >> - (void)notificationReceived { >> NSLog(@"Notification received"); >> >> AudioServicesPlaySystemSound(1005); >> >> >> if (notificationMessage && self.callbackId) { >> ``` >> >> and this works whenever we get a notification in the foreground and >> when the app is in the background. We then started tracing backwards >> in the source code to see what called notificationReceived >> >> We can see it here >> >> ``` >> - (void)register:(CDVInvokedUrlCommand *)command; { >> NSLog(@"register"); >> self.callbackId = command.callbackId; >> >> AudioServicesPlaySystemSound(1007); >> >> isInline = NO; >> >> [self.commandDelegate runInBackground:^{ >> NSMutableDictionary *options = [self parseOptions:command]; >> [self saveConfig:options]; >> >> // when running under iOS 8 we will use the new API for APNS >> registration >> #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000 >> if ([[UIApplication sharedApplication] >> respondsToSelector:@selector(registerUserNotificationSettings:)]) { >> UIUserNotificationSettings* notificationSettings = >> [UIUserNotificationSettings >> settingsForTypes:UIUserNotificationTypeAlert | >> UIUserNotificationTypeBadge | UIUserNotificationTypeSound >> categories:nil]; >> [[UIApplication sharedApplication] >> registerUserNotificationSettings:notificationSettings]; >> [[UIApplication sharedApplication] >> registerForRemoteNotifications]; >> } else { >> [[UIApplication sharedApplication] >> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | >> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)]; >> } >> >> #else >> [[UIApplication sharedApplication] >> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | >> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)]; >> #endif >> >> CDVPluginResult* pluginResult = [CDVPluginResult >> resultWithStatus:CDVCommandStatus_NO_RESULT]; >> [pluginResult setKeepCallback:@YES]; >> [self.commandDelegate sendPluginResult:pluginResult >> callbackId:command.callbackId]; >> }]; >> >> if (notificationMessage) // if there is a pending startup >> notification >> { >> AudioServicesPlaySystemSound(1024); >> >> [self notificationReceived]; // go ahead and process it >> } >> } >> ```` >> >> So we add some more beeps in to track down whats going on. We add >> AudioServicesPlaySystemSound(1007) at the beginning of the function >> and add AudioServicesPlaySystemSound(1024) just before we call the >> notificationReceived method. >> >> We get the first sounds on startup but do NOT get the second set of >> sounds. It looks like notificationMessage is not being set at >> application startup. >> >> Our problem now is that we are not Objective-C developers so we are >> struggling to debug much further. So trying to understand how >> notificationMessage is set and defined as its declared as @synthesis >> is unclear. We?ll start reading and learning quickly but as this is >> new for us, so we will be slow. >> >> Any suggestions welcomed, >> >> Rob >> >> On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote: >> >>> Hi Rob, >>> >>> What you could try is to debug this in xcode, when the notification >>> is >>> touched it should launch the app and that will in turn call the JS >>> callback. Would be good to see if this code is called 100% of the >>> time. >>> >>> You can put a breakpoint here: >>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56 >>> >>> That code will execute on cold start and here: >>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102 >>> >>> That is where the onNotification callback gets invoked. >>> >>> Hope this helps, >>> >>> On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett >>> >>> wrote: >>> >>>> Sebastien >>>> >>>> Yes, we do it at that point, $ionicPlatform.ready. I include the >>>> whole of >>>> that area of code for reference but we?re not expecting you to >>>> debug it for >>>> us. Merely to demonstrate its there. >>>> >>>> At the moment all we want the code to do is put an alert up. >>>> >>>> .run(function($ionicPlatform , CordovaService) { >>>> $ionicPlatform.ready(function() { >>>> if (window.StatusBar) { >>>> // org.apache.cordova.statusbar required >>>> StatusBar.styleDefault(); >>>> } >>>> >>>> ConsoleLog('<<< Cordova ready >>>'); >>>> >>>> /* This seems to remove an annoying page flicker on iOS when the >>>> keyboard is displayed */ >>>> cordova.plugins.Keyboard.disableScroll(true); >>>> >>>> isDeviceReady = true; >>>> >>>> var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app"; >>>> >>>> var aeroGearPushConfig = { >>>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >>>> ios: { >>>> variantID: ?XXXXX?, >>>> variantSecret: ?YYYYYYY? >>>> } , >>>> // sendMetricInfo: true, >>>> alias: uuid >>>> }; >>>> >>>> push.register(function (event) { >>>> alert("EVENT = " + JSON.stringify(event)); >>>> >>>> } , function () { >>>> if (1) >>>> { >>>> // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid)); >>>> // ConsoleLog("UUID = " + uuid); >>>> } >>>> } , function () { >>>> } , aeroGearPushConfig); >>>> >>>> We were still loading up another 18,000 lines of code so we need to >>>> start >>>> pruning that back until we have something that works. >>>> >>>> Rob >>>> >>>> On 16 Dec 2015, at 16:04, Sebastien Blanc wrote: >>>> >>>> In the ionic app when do you do the registration of UPS ? on the >>>> platformReady event ? >>>> >>>> On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett < >>>> rob.aerogear at robertwillett.com >>>> >>>> wrote: >>>> >>>> Erik, >>>> >>>> We have built the simplest possible app we can that uses the >>>> Aerogear >>>> push plugin but using the ionic tabs starter kit. >>>> >>>> http://ionicframework.com/getting-started/ >>>> >>>> We have taken the code directly from the Cordova simple app that we >>>> have >>>> got working and put it into the Ionic app. >>>> >>>> if we follow your tests as below: >>>> >>>> 1. >>>> >>>> IOS App in foreground, we send a simple push notification from the >>>> Aerogear console - Works OK, We can see the event. Good >>>> 2. >>>> >>>> IOS App in background, we send a simple push notification from the >>>> Aerogear console - Works OK, We can see the event. Good >>>> 3. >>>> >>>> IOS App killed, we send a simple push notification from the >>>> Aerogear >>>> >>>> console and some of the time when we click on the notification in >>>> the >>>> notification drawer we do NOT get the notification handler called. >>>> Not >>>> so good >>>> >>>> >>>> However it does appear to work most of the time with our minimal >>>> Ionic >>>> app, but some of the time it fails. We had a run of 1 in 2 failures >>>> when >>>> we click on the notification. Now we have just done 20 runs in a >>>> row, >>>> each time killing the app after receiving the notification and not >>>> a >>>> single failure. Nothing changed. >>>> >>>> We cannot find any obvious reason for this so we are still >>>> investigating. >>>> >>>> We have reconfigured our main app to work the same way as the >>>> minimal >>>> app but we are still getting the same issues as before, we can see >>>> the >>>> notification in the drawer but clicking on it does NOT call the >>>> same >>>> handler with the same code as the minimal app. We get zero calls to >>>> the >>>> notification event handler. >>>> >>>> We are wondering if there is a timing issue somewhere in our code, >>>> but >>>> we can?t see it. We also wondered if the size of the code we are >>>> loading is the cause of a timing issue as well. >>>> >>>> Is there any way of adding more debugging into the Aerogear push >>>> plugin >>>> to see if we can track things down that way? >>>> >>>> Its very frustrating, but thanks for your help to date. It does >>>> look >>>> like its an interaction with our code, Ionic and the Aerogear >>>> plugin. My >>>> money is on our code though. We?ll now start pulling working code >>>> out >>>> of our app until we get back to the minimal app. Only 18,604 lines >>>> to go >>>> :) >>>> >>>> Rob >>>> >>>> On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote: >>>> >>>> Hi Rob, >>>> >>>> That would be a bug, although I can not reproduce it, to test it >>>> this >>>> is >>>> what I've done to test it: >>>> $ > cordova create push-test >>>> $ > cordova platform add ios >>>> $ > cordova plugin add aerogear-cordova-push >>>> >>>> copy paste your js code into www/js/index.js onDeviceReady, changed >>>> pushServerUrl and variant info and changed quotes to " (this is >>>> your >>>> email >>>> client no doubt) and changed : into ; after console.log("Success") >>>> >>>> Attach Safari debugger and send a message when the app is in the >>>> foreground >>>> and get in the console: >>>> >>>> HandleAeroGearNotification: event => >>>> >>>> >>>> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}} >>>> >>>> I press the home button and send the app to the background send >>>> another >>>> message and 'touch' the message to launch the app: >>>> >>>> HandleAeroGearNotification: event => >>>> >>>> >>>> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}} >>>> >>>> The I kill the app by pressing home twice and swiping over the app >>>> to >>>> remove it send another message and 'touch' it to launch the app. >>>> This >>>> kills >>>> my safari debugger so no way to see the console log, but in this >>>> case >>>> coldstart should be true. To test this better changed the code to >>>> alert >>>> instead of console: >>>> >>>> function HandleAeroGearNotification(event) { >>>> alert("HandleAeroGearNotification: event => " + event.coldstart); >>>> >>>> // Stuff cut for clarity >>>> } >>>> >>>> I send another notification 'touch' it to launch the app and see >>>> the >>>> alert >>>> box display the text: >>>> >>>> HandleAeroGearNotification: event => true >>>> >>>> Hope this helps >>>> >>>> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett < >>>> rob.aerogear at robertwillett.com> wrote: >>>> >>>> Hi, >>>> >>>> We think we have found a possible bug in the Aerogear Cordova 2.0.4 >>>> push >>>> plugin specifically on the iOS side. >>>> Summary >>>> >>>> We have two versions of our app, an Android and an IOS version. >>>> Both >>>> use >>>> the latest Cordova push plugin 2.0.4. They also both have the >>>> latest >>>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and >>>> Android >>>> versions are compiled at the same time. We are running cordova >>>> 5.3.3 >>>> with >>>> Ionic 1.7.8 (?). >>>> >>>> 1. >>>> >>>> We make sure that both apps are NOT started up on each device. We >>>> also >>>> check they are NOT in the background. >>>> 2. >>>> >>>> We send the same simple notification to each device. This >>>> notification >>>> config is as below, we have anonymised the variants and alias in >>>> this >>>> JSON >>>> structure, though we can report that the UPS server sends the data >>>> correctly. We use the additionalData flag to provide the >>>> information >>>> necessary to decide which notification has been clicked in the >>>> notification >>>> drawer. >>>> >>>> 'variants' => [?variant1?,?variant2? ], >>>> 'message' => { >>>> 'additionalData' => { 'Disruption_Id' => '107546', >>>> 'EpochTime' => '1450125268' >>>> }, >>>> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction >>>> of >>>> King William Street - To facilitate a heavy lift in Cannon Street, >>>> Cannon Street will be closed. Traffic is slow moving on diversion.' >>>> }, >>>> 'alias' => [ ?alias1? ], >>>> 'ttl' => 600 >>>> }; >>>> >>>> 1. >>>> >>>> Both devices show the message, the Android device stacks the >>>> message >>>> and the iOS device display an individual message. This looks >>>> correct. >>>> 2. >>>> >>>> Clicking on the Android stacked message starts up the app and the >>>> Javascript notification handler we have defined, >>>> HandleAeroGearNotification >>>> is called >>>> >>>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) >>>> (All Directions) at the junction of King William Street - To >>>> facilitate a heavy lift in Cannon Street, Cannon Street will be >>>> closed. Traffic is slow moving on >>>> >>>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon >>>> >>>> Street (EC4N) (All Directions) at the junction of King William >>>> Street >>>> - To facilitate a heavy lift in Cannon Street, Cannon Street will >>>> be >>>> closed. Traffic is slow moving on diversion.","badge":"-1"}} >>>> >>>> 1. >>>> >>>> Clicking on the notification in the notification drawer on the iOS >>>> device also starts our app up correctly but the notification >>>> handler, >>>> HandleAeroGearNotification(), is NOT called. The app starts up as >>>> normal as >>>> if the notification had not been clicked. We would expect the >>>> notification >>>> handler to be called in iOS as it is in Android. >>>> 2. >>>> >>>> All notifications are cleared on both Android and iOS correctly >>>> when >>>> the app is started up. >>>> 3. >>>> >>>> We define HandleAeroGearNotification as >>>> >>>> var aeroGearPushConfig = { >>>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/", >>>> ios: { >>>> variantID: ?variantid_obscured?, >>>> variantSecret: ?variant_secret_obscured? >>>> } , >>>> android: { >>>> senderID: "variantid_obscured" , >>>> variantID: "variant_id_obscured" , >>>> variantSecret: "variant_secret_obscured" >>>> } , >>>> sendMetricInfo: true, >>>> alias: alias1 >>>> }; >>>> >>>> function HandleAeroGearNotification(event) { >>>> console.log(?HandleAeroGearNotification: event => ? + >>>> JSON.stringify(event)); >>>> >>>> // Stuff cut for clarity >>>> } >>>> >>>> // Slightly simplified registration event. >>>> push.register(HandleAeroGearNotification , function () { >>>> console.log(?Success?): >>>> } , function () { >>>> console.log(?Failure?); >>>> } , aeroGearPushConfig); >>>> >>>> We cannot see any reference to this issue in the JIRA database and >>>> wondered if it is a bug or not. >>>> >>>> If its a bug we are happy to raise it accordingly. >>>> >>>> Please let us know, >>>> >>>> Thanks >>>> >>>> Rob >>>> ------------------------------ >>>> >>>> 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 >>>> >>>> ------------------------------ >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> 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 > _______________________________________________ > 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/20151220/9edce98a/attachment-0001.html From matzew at apache.org Wed Dec 23 10:17:35 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Dec 2015 16:17:35 +0100 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 In-Reply-To: References: <4DF9C801E930464B8345609FA14E8A3C242BA86D@MAIL2010.petafuel.intern> Message-ID: Hi Marius, looks like with the recent Keycloak version (1.7.0), this issue is no longer present. On master we already have KC 1.7.0 as our main server. Would it help if we get a 1.2.0-alpha.1 out early January? (that would be basically 1.1.1 + KC 1.7.0) On Thu, Dec 17, 2015 at 6:47 PM, Matthias Wessendorf wrote: > Hello Marius, > > regarding your transaction code, I filed this ticket: > https://issues.jboss.org/browse/KEYCLOAK-2235 > > Didn't get to do some docker/postgres 9.3 tests > > But for my shell history, I was using 9.3 - but not sure if w/ EAP (6.3.x > / 6.4.1) or WildFly > > More on Doccker tomorrow > > On Thu, Dec 17, 2015 at 11:10 AM, Matthias Wessendorf > wrote: > >> Hello Marius, >> >> sorry for the late reply - your mail was stuck in the moderators queue. >> Did you subscribe before sending? Anyways. >> >> I am not sure about this issue, looks like there is a bug in the "old" >> Keycloak we use, on 1.1.0 of UPS. >> We are in the process of updating it to a more recent version of Keycloak >> (1.7.0): >> https://github.com/aerogear/aerogear-unifiedpush-server/pull/659 >> >> Can you file a JIRA against Keycloak -> >> http://JIRA.jboss.org/browse/KEYCLOAK >> >> We have done a bit of testing w/ UPS 1.1.0 and Postgres9 - but I am, tbh, >> not sure if we did test w/ 9.3 :/ >> >> I will create docker-compose files, that will use this DB for our own >> testing of UPS. I will share my evaluations of this later (today/tomorow) >> >> Sorry for the inconvenience! >> >> HTH, >> Matthias >> >> On Mon, Dec 14, 2015 at 4:48 PM, Marius Schellenberger < >> marius.schellenberger at petafuel.de> wrote: >> >>> Hello AeroGear dev?s, >>> >>> >>> >>> I?m currently evaluating the AeroGear Unified Push Server in a >>> pre-production environment (RedHat JBoss EAP 6.4.4) and I?m facing an issue >>> with an idle database transaction, which is executed every time the app is >>> deployed (or the JBoss Server is started). >>> >>> >>> >>> I?m using Postgresql 9.3 as the database backend. >>> >>> >>> >>> The idle process listed in ps aux: >>> >>> postgres: keycloak keycloak 10.0.6.106(55387) idle in transaction >>> >>> >>> >>> The transaction seems to hang at this SQL statement: >>> >>> select authentica0_.REALM_ID as REALM_ID4_28_1_, authentica0_.ID as >>> ID1_3_1_, authentica0_.ID as ID1_3_0_, authentica0_.ALIAS as ALIAS2_3_0_, >>> authentica0_.PROVIDER_ID as PROVIDER3_3_0_, authentica0_.REALM_ID as >>> REALM_ID4_3_0_ from AUTHENTICATOR authentica0_ where >>> authentica0_.REALM_ID=$1 >>> >>> >>> >>> The query results nothing, as you can see below: >>> >>> select * from AUTHENTICATOR; >>> >>> id | alias | realm_id | provider_id >>> >>> ----+-------+----------+------------- >>> >>> (0 rows) >>> >>> >>> >>> Can you guys please help me identifying this issue? >>> >>> >>> >>> Kind regards, >>> >>> >>> >>> Marius Schellenberger >>> >>> >>> >>> _______________________________________________ >>> 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 > -- 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/20151223/6c7a1478/attachment.html From marius.schellenberger at petafuel.de Wed Dec 23 10:39:44 2015 From: marius.schellenberger at petafuel.de (Marius Schellenberger) Date: Wed, 23 Dec 2015 15:39:44 +0000 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 In-Reply-To: References: <4DF9C801E930464B8345609FA14E8A3C242BA86D@MAIL2010.petafuel.intern> Message-ID: <4DF9C801E930464B8345609FA14E8A3C242EEDA5@MAIL2010.petafuel.intern> Hi Matthias, early January sounds great. Just let me know when I can start testing the master branch in the preproduction environment. I will let you know my experiences. Thank you very much for your help! Best regards Marius Hi Marius, looks like with the recent Keycloak version (1.7.0), this issue is no longer present. On master we already have KC 1.7.0 as our main server. Would it help if we get a 1.2.0-alpha.1 out early January? (that would be basically 1.1.1 + KC 1.7.0) On Thu, Dec 17, 2015 at 6:47 PM, Matthias Wessendorf < matzew at apache.org> wrote: Hello Marius, regarding your transaction code, I filed this ticket: https://issues.jboss.org/browse/KEYCLOAK-2235 Didn't get to do some docker/postgres 9.3 tests But for my shell history, I was using 9.3 - but not sure if w/ EAP (6.3.x / 6.4.1) or WildFly More on Doccker tomorrow On Thu, Dec 17, 2015 at 11:10 AM, Matthias Wessendorf < matzew at apache.org> wrote: Hello Marius, sorry for the late reply - your mail was stuck in the moderators queue. Did you subscribe before sending? Anyways. I am not sure about this issue, looks like there is a bug in the "old" Keycloak we use, on 1.1.0 of UPS. We are in the process of updating it to a more recent version of Keycloak (1.7.0): https://github.com/aerogear/aerogear-unifiedpush-server/pull/659 Can you file a JIRA against Keycloak -> http://JIRA.jboss.org/browse/KEYCLOAK We have done a bit of testing w/ UPS 1.1.0 and Postgres9 - but I am, tbh, not sure if we did test w/ 9.3 :/ I will create docker-compose files, that will use this DB for our own testing of UPS. I will share my evaluations of this later (today/tomorow) Sorry for the inconvenience! HTH, Matthias On Mon, Dec 14, 2015 at 4:48 PM, Marius Schellenberger < marius.schellenberger at petafuel.de> wrote: Hello AeroGear dev?s, I?m currently evaluating the AeroGear Unified Push Server in a pre-production environment (RedHat JBoss EAP 6.4.4) and I?m facing an issue with an idle database transaction, which is executed every time the app is deployed (or the JBoss Server is started). I?m using Postgresql 9.3 as the database backend. The idle process listed in ps aux: postgres: keycloak keycloak 10.0.6.106(55387) idle in transaction The transaction seems to hang at this SQL statement: select authentica0_.REALM_ID as REALM_ID4_28_1_, authentica0_.ID as ID1_3_1_, authentica0_.ID as ID1_3_0_, authentica0_.ALIAS as ALIAS2_3_0_, authentica0_.PROVIDER_ID as PROVIDER3_3_0_, authentica0_.REALM_ID as REALM_ID4_3_0_ from AUTHENTICATOR authentica0_ where authentica0_.REALM_ID=$1 The query results nothing, as you can see below: select * from AUTHENTICATOR; id | alias | realm_id | provider_id ----+-------+----------+------------- (0 rows) Can you guys please help me identifying this issue? Kind regards, Marius Schellenberger _______________________________________________ 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 -- 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/20151223/2d2773c2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5073 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-users/attachments/20151223/2d2773c2/attachment-0001.bin From matzew at apache.org Wed Dec 23 10:45:49 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Dec 2015 16:45:49 +0100 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 In-Reply-To: <4DF9C801E930464B8345609FA14E8A3C242EEDA5@MAIL2010.petafuel.intern> References: <4DF9C801E930464B8345609FA14E8A3C242BA86D@MAIL2010.petafuel.intern> <4DF9C801E930464B8345609FA14E8A3C242EEDA5@MAIL2010.petafuel.intern> Message-ID: Hi Marius, you can already use it today, as the master branch is on 1.7.0. To build the distribution/release binaries, simply run: mvn clean install -Pdist,test and in the "dist/target" folder, you'll find the WAR files, as part of the "aerogear-unifiedpush-server-1.2.0-SNAPSHOT-dist.tar.gz" file. I think this would be good, if you can tell us if the KC bug in question has been fixed, and that way we also don't need to 'rush' on such an alpha.1 release. Makes sense? -Matthias On Wed, Dec 23, 2015 at 4:39 PM, Marius Schellenberger < marius.schellenberger at petafuel.de> wrote: > Hi Matthias, > > > > early January sounds great. > > > > Just let me know when I can start testing the master branch in the > preproduction environment. > > I will let you know my experiences. > > > > Thank you very much for your help! > > > > Best regards > > Marius > > > > Hi Marius, > > > > looks like with the recent Keycloak version (1.7.0), this issue is no > longer present. > > > > On master we already have KC 1.7.0 as our main server. Would it help if we > get a 1.2.0-alpha.1 out early January? > > (that would be basically 1.1.1 + KC 1.7.0) > > > > On Thu, Dec 17, 2015 at 6:47 PM, Matthias Wessendorf > wrote: > > Hello Marius, > > > > regarding your transaction code, I filed this ticket: > > https://issues.jboss.org/browse/KEYCLOAK-2235 > > > > Didn't get to do some docker/postgres 9.3 tests > > > > But for my shell history, I was using 9.3 - but not sure if w/ EAP (6.3.x > / 6.4.1) or WildFly > > > > More on Doccker tomorrow > > > > On Thu, Dec 17, 2015 at 11:10 AM, Matthias Wessendorf > wrote: > > Hello Marius, > > > > sorry for the late reply - your mail was stuck in the moderators queue. > Did you subscribe before sending? Anyways. > > > > I am not sure about this issue, looks like there is a bug in the "old" > Keycloak we use, on 1.1.0 of UPS. > > We are in the process of updating it to a more recent version of Keycloak > (1.7.0): > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/659 > > > > Can you file a JIRA against Keycloak -> > http://JIRA.jboss.org/browse/KEYCLOAK > > > > We have done a bit of testing w/ UPS 1.1.0 and Postgres9 - but I am, tbh, > not sure if we did test w/ 9.3 :/ > > > > I will create docker-compose files, that will use this DB for our own > testing of UPS. I will share my evaluations of this later (today/tomorow) > > > > Sorry for the inconvenience! > > > > HTH, > > Matthias > > > > On Mon, Dec 14, 2015 at 4:48 PM, Marius Schellenberger < > marius.schellenberger at petafuel.de> wrote: > > Hello AeroGear dev?s, > > > > I?m currently evaluating the AeroGear Unified Push Server in a > pre-production environment (RedHat JBoss EAP 6.4.4) and I?m facing an issue > with an idle database transaction, which is executed every time the app is > deployed (or the JBoss Server is started). > > > > I?m using Postgresql 9.3 as the database backend. > > > > The idle process listed in ps aux: > > postgres: keycloak keycloak 10.0.6.106(55387) idle in transaction > > > > The transaction seems to hang at this SQL statement: > > select authentica0_.REALM_ID as REALM_ID4_28_1_, authentica0_.ID as > ID1_3_1_, authentica0_.ID as ID1_3_0_, authentica0_.ALIAS as ALIAS2_3_0_, > authentica0_.PROVIDER_ID as PROVIDER3_3_0_, authentica0_.REALM_ID as > REALM_ID4_3_0_ from AUTHENTICATOR authentica0_ where > authentica0_.REALM_ID=$1 > > > > The query results nothing, as you can see below: > > select * from AUTHENTICATOR; > > id | alias | realm_id | provider_id > > ----+-------+----------+------------- > > (0 rows) > > > > Can you guys please help me identifying this issue? > > > > Kind regards, > > > > Marius Schellenberger > > > > > > _______________________________________________ > 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 > > > > > > -- > > 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 > > -- 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/20151223/a7085828/attachment.html From marius.schellenberger at petafuel.de Wed Dec 23 11:31:37 2015 From: marius.schellenberger at petafuel.de (Marius Schellenberger) Date: Wed, 23 Dec 2015 16:31:37 +0000 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 Message-ID: <14a8312b-8cbb-4152-bc4a-48ed000822e3@email.android.com> Hi Matthias, alright, give me some days to test. I think next week I will have the results. Best regards Marius -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151223/3cb59c19/attachment.html From matzew at apache.org Wed Dec 23 11:35:09 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Dec 2015 17:35:09 +0100 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 In-Reply-To: <14a8312b-8cbb-4152-bc4a-48ed000822e3@email.android.com> References: <14a8312b-8cbb-4152-bc4a-48ed000822e3@email.android.com> Message-ID: Perfecto! have a nice xmas break! On Wed, Dec 23, 2015 at 5:31 PM, Marius Schellenberger < marius.schellenberger at petafuel.de> wrote: > Hi Matthias, > > alright, give me some days to test. > I think next week I will have the results. > > Best regards > Marius > > _______________________________________________ > 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/20151223/71d298ff/attachment-0001.html From marius.schellenberger at petafuel.de Tue Dec 29 05:46:30 2015 From: marius.schellenberger at petafuel.de (Marius Schellenberger) Date: Tue, 29 Dec 2015 10:46:30 +0000 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 In-Reply-To: References: <14a8312b-8cbb-4152-bc4a-48ed000822e3@email.android.com> Message-ID: <4DF9C801E930464B8345609FA14E8A3C242F4494@MAIL2010.petafuel.intern> Dear Matthias, I got the newest commit (880de40) running. Now there are two idle transactions on the database, instead of one. The SQL statement has also changed. select pid,datname,query from pg_stat_activity where pid = 27622 or pid = 27714; pid | datname | query -------+----------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 27622 | keycloak | select defaultgro0_.REALM_ID as REALM_ID1_28_1_, defaultgro0_.GROUP_ID as GROUP_ID2_31_1_, groupentit1_.ID as ID1_21_0_, groupentit1_.NAME as NAME2_21_0_, groupentit1_.PARENT_GROUP as PARENT_G3_21_0_, groupentit1_.REALM_ID as REALM_ID4_21_0_ from REALM_DEFAULT_GROUPS defaultgro0_ inner join KEYCLOAK_GROUP groupentit1_ on defaultgro0_.GROUP_ID=groupentit1_.ID where defaultgro0_.REALM_ID=$1 27714 | keycloak | select defaultgro0_.REALM_ID as REALM_ID1_28_1_, defaultgro0_.GROUP_ID as GROUP_ID2_31_1_, groupentit1_.ID as ID1_21_0_, groupentit1_.NAME as NAME2_21_0_, groupentit1_.PARENT_GROUP as PARENT_G3_21_0_, groupentit1_.REALM_ID as REALM_ID4_21_0_ from REALM_DEFAULT_GROUPS defaultgro0_ inner join KEYCLOAK_GROUP groupentit1_ on defaultgro0_.GROUP_ID=groupentit1_.ID where defaultgro0_.REALM_ID=$1 Also when I kill these transactions manually using select pg_terminate_backend(27622); select pg_terminate_backend(27714); the transactions seem to never show up again. The idle transactions are back if the JBoss server is restarted or the App is redeployed. Please tell me if you need any more information. Best regards Marius Perfecto! have a nice xmas break! On Wed, Dec 23, 2015 at 5:31 PM, Marius Schellenberger > wrote: Hi Matthias, alright, give me some days to test. I think next week I will have the results. Best regards Marius _______________________________________________ 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/20151229/3778b262/attachment.html From matzew at apache.org Tue Dec 29 11:08:35 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Dec 2015 17:08:35 +0100 Subject: [Aerogear-users] Idle in transaction using AeroGear Unified Push 1.1.0 and postgresql 9.3 In-Reply-To: <4DF9C801E930464B8345609FA14E8A3C242F4494@MAIL2010.petafuel.intern> References: <14a8312b-8cbb-4152-bc4a-48ed000822e3@email.android.com> <4DF9C801E930464B8345609FA14E8A3C242F4494@MAIL2010.petafuel.intern> Message-ID: Hi Marius, can you comment on https://issues.jboss.org/browse/KEYCLOAK-2235 and reopen the ticket? Thanks On Tuesday, 29 December 2015, Marius Schellenberger < marius.schellenberger at petafuel.de> wrote: > Dear Matthias, > > > > I got the newest commit (880de40) running. > > > > Now there are two idle transactions on the database, instead of one. > > > > The SQL statement has also changed. > > > > select pid,datname,query from pg_stat_activity where pid = 27622 or pid = > 27714; > > pid | datname > | > query > > > > -------+----------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > 27622 | keycloak | select defaultgro0_.REALM_ID as REALM_ID1_28_1_, > defaultgro0_.GROUP_ID as GROUP_ID2_31_1_, groupentit1_.ID as ID1_21_0_, > groupentit1_.NAME as NAME2_21_0_, groupentit1_.PARENT_GROUP as > PARENT_G3_21_0_, groupentit1_.REALM_ID as REALM_ID4_21_0_ from > REALM_DEFAULT_GROUPS defaultgro0_ inner join KEYCLOAK_GROUP groupentit1_ on > defaultgro0_.GROUP_ID=groupentit1_.ID where defaultgro0_.REALM_ID=$1 > > 27714 | keycloak | select defaultgro0_.REALM_ID as REALM_ID1_28_1_, > defaultgro0_.GROUP_ID as GROUP_ID2_31_1_, groupentit1_.ID as ID1_21_0_, > groupentit1_.NAME as NAME2_21_0_, groupentit1_.PARENT_GROUP as > PARENT_G3_21_0_, groupentit1_.REALM_ID as REALM_ID4_21_0_ from > REALM_DEFAULT_GROUPS defaultgro0_ inner join KEYCLOAK_GROUP groupentit1_ on > defaultgro0_.GROUP_ID=groupentit1_.ID where defaultgro0_.REALM_ID=$1 > > > > Also when I kill these transactions manually using > > select pg_terminate_backend(27622); > > select pg_terminate_backend(27714); > > > > the transactions seem to never show up again. > > > > The idle transactions are back if the JBoss server is restarted or the App > is redeployed. > > > > Please tell me if you need any more information. > > > > Best regards > > Marius > > > > > > > > Perfecto! > > > > have a nice xmas break! > > > > On Wed, Dec 23, 2015 at 5:31 PM, Marius Schellenberger < > marius.schellenberger at petafuel.de > > > wrote: > > Hi Matthias, > > alright, give me some days to test. > I think next week I will have the results. > > Best regards > Marius > > > _______________________________________________ > 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 > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151229/b7bad234/attachment-0001.html From aamagdi at ejada.com Wed Dec 30 09:02:45 2015 From: aamagdi at ejada.com (aamagdi) Date: Wed, 30 Dec 2015 07:02:45 -0700 (MST) Subject: [Aerogear-users] UPS High Availability Message-ID: <1451484165726-394.post@n5.nabble.com> Hi I planning to deploy UPS 1.1 with a cluster configuration on jBoss 6.4, I want to ask about UPS high availability capabilities. For example for the below scenario: 1- A call sent to UPS rest sender api for a push notification with out define any aliases / variant or categories. 2- UPS have about 10,000 registered mobile devices. 3- What I have understand from UPS guide that the default batch size is 1000 so this call will be split into 10 batches each batch have 1000 device, and UPS will start sending one batch after another. 4- After sending two batches the sever goes down or some failure occurred. 5- Switching to the second server node of the UPS Will it resume sending the request handled by the first node? or the request will lost? Thanks, Abdalla -- View this message in context: http://aerogear-users.1116366.n5.nabble.com/UPS-High-Availability-tp394.html Sent from the aerogear-users mailing list archive at Nabble.com.