AeroGear Crypto Java 0.1.2 released
by Bruno Oliveira
Good morning, just to let you know we released today the bits for digital signatures and some bug fixes.
Have a happy new year sweet hearts.
--
abstractj
4 years, 1 month
AeroGear WebPush Java Client
by Idel Pivnitskiy
Hi all!
I've just implemented a lightweight java client for receiving push messages
from AeroGear WebPush Server [1]. It is easy to use and fully async!
A few words about decision to use Jetty as a HTTP/2 client:
Currently there are only 3 Java libraries, which implement client side of
HTTP/2 protocol [2]: Netty, Jetty and OkHttp. I tried all of them:
- First of all I tried to use OkHttp. This is a lightweight http client
for Android and other Java apps. But currently this library supports HTTP/2
protocol only via old HTTP/1.1 API. It works well for simple
request-response, but its client API does not allow to use HTTP/2 features,
like Server Push Frames. I looked at GRPC [3], because Googlers use OkHttp
for HTTP/2 transport. But they don't use public API, they use only inner
classes to handle frames and built their own logic atop this classes. It
would be too complicated for our purposes.
- Secondary, I tried to refactor our WebPush console to a client
library. But this way is complicated too. netty-codec-http2 does not
provide a client API, it is only codec, low level protocol implementation.
- Now I use jetty-http2-client. It is easy to configure and use, fast
and async. Jetty provides a user friendly API to handle HTTP/2 streams and
get PUSH_PROMISE frames.
For more information, look at my commit history.
In the future, if there will be more lightweight alternatives than Jetty
(for example, new version of OkHttp or Java 9 API), I will rewrite the
transport layer of my library.
Here is an example, how to use my library [4].
[1] https://github.com/idelpivnitskiy/aerogear-webpush-java-client
[2] https://github.com/http2/http2-spec/wiki/Implementations
[3] https://github.com/grpc/grpc-java/tree/master/okhttp
[4]
https://github.com/idelpivnitskiy/aerogear-webpush-java-client/blob/maste...
Best regards,
Idel Pivnitskiy
--
E-mail: Idel.Pivnitskiy(a)gmail.com
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
10 years, 4 months
GCM Topics in UPS
by Summers Pittman
So I've got a few ideas for how to implement this, but I hope some people
more experienced with the platform can give some feedback before.
Quick Background:
In UPS right now we have a concept of categories. A single UPS message can
be broadcast to a bunch of devices which are subscribed to this category.
Google now supports this for GCM on Chrome, iOS, and Android so UPS can
send a single message to GCM and GCM will broadcast that to up to a million
devices.
End Quick Background
So first, how do we switch between sending a message to each device in a
category to sending a topic message to GCM?
In TokenLoader.java#L113 we are using the clientInstallationService to
build a string of deviceTokens based on the variant and message criteria.
Is there any reason we can't create a "topicToken" which will be recognized
later by GCMPushNotificationSender? Another benefit to making this change
here is that if we have over a million subscribers to the category we can
just default to the default messaging.
There is also an open issue of whether or not we will update the clients to
filter based on what category a message was sent to. To do this we will
have to include the category information in the message when we send it to
devices going forward. In GCM a topic message includes this information.
This means that if we have over a million subscriptions in the topic we
will need to fall back to using the category information anyway.
Continuing on from the thread of falling back, it is possible for a topic
message to fail to send because there are too many subscribers. How would
UPS handle regenerating the messages as deviceToken instead of topicToken
messages?
Of course if someone has a better idea than "topicTokens" I'm all ears.
10 years, 4 months
UPS using JMS update
by Lukáš Fryč
Hi guys,
so as outlined in previous thread [1], I have prototyped a JMS batching
approach for push message delivery.
We've discussed the approach with Matthias, Mirek Novak and Ondrej
Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents
describes a concept that we have came with:
Diagram:
https://docs.google.com/a/fryc.eu/drawings/d/13IsJWPSJNYXtst-UVxQYmzH36C_...
Text Doc:
https://docs.google.com/document/d/1X65P_U9O62Z5JZhKi9ZvBuZU1OrL4pNHNddlz...
Implementation-wise, I've so far prototyped the messaging part (split
SenderService functionality to two subsequent queues with MDBs as shown on
diagram),
but that's just a start, since we must configure it appropriately for
efficiency (queue configuration and batch sizes) and verify that
configuration works as expected,
the prototype lives on a branch (unpolished, to be squashed later):
https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching
Off course, you can play with it already. :-)
Apart from the new requirement of using Java EE full profile (JMS), the
prototype leverages implementation-specific configurations and APIs:
- org.hibernate.Query for token streaming / batch fetching
- HornetQ configurations of queue size, blocking behavior and message
de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any
compliant app server, but without specific configurations it won't work
properly.
Once configured and functionally tested (that can even wait for Beta2 I
guess),
we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite
contains mocks of APNS/GCM against which we can load test.
Cheers!
~ Lukas
[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-new-re...
10 years, 8 months
SimplePush Polyfill work
by Luke Holmquist
so now that WebPush is going to take over SimplePush, i'm thinking of
closing the related JIRA's that we have open for simple push in the AG-JS
instance.
Not that we've really done any work on it lately, but it would be good to
clean this up a little.
Thoughts?
-Luke
10 years, 10 months
UnifiedPush js client
by Luke Holmquist
so i decided to take a gander at the push client lib in the aerogear.js
project. Currently if someone would like to use it, they have a couple
options.
1. download the whole lib,
2. download a custom build from the website
3. download a custom build from bower
4. create a custom build from source
In the past i think i was against breaking out pieces of the JS lib into
separate repo's since we could just use the AeroGearComponents repo i
created for custom builds. But i think with the state of the JS lib(not
sure where it's going), it might make sense to, at least with the push
lib(perhaps the simplePush polyfill also) to break those out into separate
repo's similar to the other client projects.
I think the starting vision of the project has changed, so perhaps this
change is good.(this should probably be a whole separate thread)
Now that Chrome and Safari have push in the browser, FF is getting it also
very soon, it's possible this part of the library will be used more
thoughts?
-Luke
10 years, 10 months
Android Dependencies and DEX Size
by Artur Dryomov
Hi everyone,
So, I’ve just hit the famous 65 K methods count and DEX error as a sweet
bonus while updating the application to latest Android 6.0-related
dependencies.
Long story short, I’ve analyzed [1] dependencies [2] for the Hawkular
Android Client [3]. Important notice—the application is not that big or
complicated.
Methods count is below.
- Various dependencies: 2445.
- Java & JavaX: 1684.
- Android Support libraries: 12988.
- Android: 3081.
- Google Play Services: 22022.
- Bouncycastle: 10423.
- Spongycastle: 10423.
- AeroGear: 1210.
- Application itself: 1047.
- Total: 65346.
This is kind of disappointing. Of course I can start to blame Android
Support libraries, but you clearly cannot develop apps these days without
using backports and helpers. Google Play Services is a bigger deal. It is a
dependency of the AeroGear Push module and you cannot live without it as
well, but you can use a modular dependency. I’ve addressed this in an issue
[4] which leads to another one [5]. It was fixed (there is Google Play
Services 7.8.0 already though), but not released. Bouncycastle and
Sprongycastle are related to security and are dependencies of the AeroGear
Store module which is a dependency of the AeroGear Authz module. I’m not
really sure I need this at all.
Let’s count again.
- The current application: 65346 methods.
- The application without Google Play Services and Castles: 22478.
The application can be (65346 ÷ 22478 = 2.9) times smaller.
What do you think about? Is there any chance to ditch these Castle
dependencies and release the new Push version?
Regards,
Artur.
[1]: http://inloop.github.io/apk-method-count
[2]: http://pastie.org/private/27y3igg4imyqfjvs9qz9a
[3]: https://github.com/hawkular/hawkular-android-client
[4]: https://issues.jboss.org/browse/AGDROID-432
[5]: https://issues.jboss.org/browse/AGDROID-351
10 years, 10 months
UPS 1.1.0-beta.4 and Openshift release (was: Re: Staging of UPS 1.1.0-beta.4 (was: Re: Staging of UPS 1.1.0.Final))
by Matthias Wessendorf
Hello folks!
On our way to 1.1.0.Final, we have released another beta release! This
release contains changes to the DB schema and other small improvements.
List of JIRAs
https://issues.jboss.org/browse/AGPUSH/fixforversion/12327878
The release has been uploaded to Maven Central:
http://search.maven.org/#search%7Cga%7C1%7Cunifiedpush
It's, as usually, available on github too:
https://github.com/aerogear/aerogear-unifiedpush-server/releases/tag/1.1....
Openshift update:
As we move towards 1.1.0, the Openshift cartridge has been updated too, the
new beta 4 is available on Openshift:
https://github.com/aerogear/openshift-origin-cartridge-aerogear-push#inst...
Greetings,
Matthias
On Mon, Aug 17, 2015 at 8:28 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> Hello,
>
> since we had a few issues found and serious changes on the underlying DB
> schema (see Karel's mail), here is the staging of another beta:
>
>
> https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
>
>
>
> Idea is to afterwards have a stable time of a week, and get the
> 1.1.0.Final, finally out!
>
> Any comments?
>
> -Matthias
>
>
> On Wed, Aug 12, 2015 at 8:52 AM, Sebastien Blanc <scm.blanc(a)gmail.com>
> wrote:
>
>> Yes, I will discard the current staged release.
>> Thanks Erik for reporting these issues.
>>
>>
>>
>> On Tue, Aug 11, 2015 at 10:39 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>>> I think this is aldo worth to be included to 1.1.0.Final
>>>
>>>
>>> On Tuesday, August 11, 2015, Erik Jan de Wit <edewit(a)redhat.com> wrote:
>>>
>>>> I found these issues:
>>>>
>>>>
>>>> 1. AGPUSH-1492 <https://issues.jboss.org/browse/AGPUSH-1492> Deleting
>>>> an Application leaves installations
>>>> 2.
>>>> 1.
>>>> 1. AGPUSH-1491 <https://issues.jboss.org/browse/AGPUSH-1491> Android
>>>> doesn't show installations
>>>>
>>>>
>>>> On Tue, Aug 11, 2015 at 1:06 PM, Matthias Wessendorf <matzew(a)apache.org
>>>> > wrote:
>>>>
>>>>> looking...
>>>>>
>>>>> On Fri, Aug 7, 2015 at 3:48 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi team,
>>>>>>
>>>>>> I'm happy to announce that UPS 1.1.0 Final has been staged.
>>>>>>
>>>>>> Please test the staged release :
>>>>>>
>>>>>>
>>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
>>>>>>
>>>>>> On Wednesday I'd like to press the button to release it to the wild.
>>>>>>
>>>>>> Sebi
>>>>>>
>>>>>> ps : the openshift update will follow
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Erik Jan
>>>>
>>>
>>>
>>> --
>>> Sent from Gmail Mobile
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 10 months
