As we've discussed a few weeks ago, aerogear.org had a lot of old files
lying around the server, and I've volunteered to take a weekend and do
the site cleanup (delete everything and re-upload the new stuff).
So I've just did it!
Please let me know if you find any issues with aerogear.org!
Aloha, freenode was compromised. Change your IRC passwords, please.
"Earlier today the freenode infra team noticed an anomaly on a single
IRC server. We have since identified that this was indicative of the
server being compromised by an unknown third party. We immediately
started an investigation to map the extent of the problem and located
similar issues with several other machines and have taken those offline.
For now, we recommend that everyone change their NickServ password as a
We’ll issue more updates as WALLOPS and via social media!"
We found a issue in the 1.0.0 release of the push plugin, one of it's dependencies change in a way that it's no longer working for android. We'll fix this in the 1.0.1 release, I've created a branch 1.0.1-release for testing. If all is well the release will be synced with the UPS 1.0.1 release.
 the fix https://github.com/gorkem/aerogear-pushplugin-cordova/commit/c960d852e8f8...
for the 1.1.x (master) we are potentially doing some changes on the
Sender-API (see ).
However, for backwards compatibility we need to think about API versioning.
For REST APIs there are (IMO) two options:
* accept header
On our Face2Face meeting we briefly talked about this and I think the
"accept header" solution was the one that had most fans. I think QMX added
that it is better for migration. One thing we were not clear on (I think):
What are HATEOS defined semantics?
Besides the what (headers vs. URI), I think we should think about possible
implementations, to switch different versions.
Not sure, but wouldn't it be possible to inject an annotated SenderService
into the RESTful endpoint, based on header values ?
We could have a default impl (version 1.0.0) and an alternate one, that is
injected if the accept header indicate API version 1.1
Any thoughts ?
Good morning my friends, we've been working together with Keycloak since
the beginning and the KC team did a hard work to meet our requirements
For this reason, I would like your help on testing mostly Keycloak. It's
a huge step to everyone.
- git clone email@example.com:keycloak/keycloak.git && cd keycloak && mvn
clean install -DskipTests=true
- git clone firstname.lastname@example.org:aerogear/aerogear-unifiedpush-server.git &&
cd aerogear-unifiedpush-server && git checkout keycloak_final && mvn
clean install -DskipTests=true
- Deploy on WildFly or JBoss
I also deployed it on OpenShift
https://golum-abstractj.rhcloud.com/ag-push. User: admin pass: 123. Please make sure to test on multiple browsers.
Please make sure to reply on this thread
with issues found.
If you don't want to test anything, sooner or later the problem will hit you ;)
I'm building the cordova support, but there is a bit of an issue, right now we support windows WNS message, these 'only' work for windows phone 8.1. Seems though that cordova projects are for multiple versions 8.0 also being one of them. This means that WNS will not work on cordova, but the older MPNS will. The client library already supports both, but UPS not yet. The problem now is how do we support both of these on UPS. The most simple solution is to have 2 variant types WindowsWNSVariant and WindowsMPNSVariant, that we can have 2 sender implementations for both protocols. We could still group these together somehow on the UI. What do you think?
I started some days ago a Unified Push Server 0.10.4 using the
openshift aerogear quickstart cartridge.
After hearing that the cartridge has to be updated due to security
reasons on openshift I wondered:
Is it possible to update the cartridge via taking snapshots or something?
Can I update this cartridge to the security fixed cartridge version (0.10.4)?
Or has it to be updated to the latest release?