aerogear-unified-push-java-client 0.2.0 released
by Sebastien Blanc
Hi Folks,
I'm happy to announce the release of aerogear-unified-push-java-client
0.2.0.
With this release, thanks to the fluent API it will be even easier to send
messages to the Push Server.
This is the staging repo :
https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
Here is the changelog :
* added missing descrs and minor formatting
* adding javadoc to the getters
* refactor to have category, deviceType and variants on the correct level
* javadoc in-sync with the guide
* moved to attributes map instead of fields
* added test case
* missing getter for variants
* be specific on ids
* added missing variants param.
* remove unused param.
* missing throw
* small typo
* renamed the tag name to unified-push-java-client
* rename artifact to unified-push-java-client
* Merge remote-tracking branch 'qmx/release_cleanups'
* fix formatting
* update developer section
* add scm section
* fix javadoc warnings and polish
* add a some javadoc to the buildUrl method
* add a non args constructor + extrac checks for serverURL
* README update, selective send section should use sendTo
* Merge branch 'parent_pom'
* add aerogear's parent pom
* fix pom formatting
* fixing conflicts
* fixed unit test
* moved Strings to fields, extra test cases, null check
* simple-push auto version fix
* more javadoc polishing
* updated javadoc
* more JavaDoc
* added some Javadoc
* add category, deviceType and rename identifiers to aliases
* change the version and update the readme
* Fixing merge conflicts
* first version of UnifiedMessage Builder
* fixed unit test
* moved Strings to fields, extra test cases, null check
* simple-push auto version fix
* more javadoc polishing
* updated javadoc
* more JavaDoc
* added some Javadoc
* Merge branch 'AGPUSH-135' of
https://github.com/aerogear/aerogear-unified-push-java-client into
AGPUSH-135
* add category, deviceType and rename identifiers to aliases
* first version of UnifiedMessage Builder
* Merge branch 'master' of
https://github.com/aerogear/aerogear-unified-push-java-client
* Polishing the JAva Sender Client
* Merge branch 'readme_update'
* Update Readme example code
* Adding a finally block and a disconnect(), to release resources
* change the version and update the readme
* first version of UnifiedMessage Builder
* Keep it simple
* moving to httpurlconnection
* Merge branch 'license_fixes'
* fix license headers
* Merge branch 'formatting'
* fix formatting
Please enjoy, test and report bugs !
Seb
13 years
[SimplePush] Subsystem
by Daniel Bevenius
Hi,
I'm about to update the Netty subsystem to make some changes after the
feedback we got from the WildFly team [1].
I'm indenting to first address the concerns about the extra xml element,
use a module attribute to point where the factory class is located, and
then the threading tips.
They also recommended that we create a specific subsystem for SimplePush.
The advantage of this as I see it is that we would then have a schema for
the configuration options for SimplePush (and also the SockJS configuration
options). Without this we need to add a generic properties element to the
Netty subsystem.
Another advantage would also be just having one single module instead of
two like we currently have (one for the Netty subsystem and one for
SimplePush).
One disadvantage might be if we later would like the Unified Push Server to
be base on Netty it would also have to have a specific subsystem.
I wanted to people think is the right approach here for us?
[1] https://community.jboss.org/thread/229635;cid=1374049762089-667
13 years
shiny objects
by Lucas Holmquist
So most of you all know my love of shiny objects. With the release of 0.0.2 of the Admin UI, i decided to make yesterday( friday. 8/2 ) a day about experimenting.
A while ago i started to play with Chrome Packaged Apps and sending Push messages to them with GCM for Chrome[1] and how we could integrate that service into the Unified Push Server. My first attempt back then failed, so i decided to have another go at it. I'm happy to report that i got it working this time.
I created a chrome branch[2] in my fork of the Push server and also a chrome branch[3] in my fork of the admin UI.
Just a quick rundown of how this messaging works:
1. you create an app in the google api console thing - same as android
2. Then you need to generate a refresh and access token - this is different than android
** the refresh token doesn't expire unless explicitly revoked, but the access token does every 60 minutes(?)
3. Send the message with the client id, client secret( these 2 are generated from step 1 ) and the access token
it is not recommend to get a new access token for every request since there is a limit.
Integrating this into the push server wasn't to bad, just tedious because of all the interfaces and such.
probably the crappiest code is the actual sender that i wrote( actually taken from the simple push sender ). It gets a new access token every time which as i stated before is bad.
I'm not sure if we should store the access token with the timer or what. The model that i created for this has a clientId, clientSecret, and a refreshToken
here is the sample code that i threw together for receiving the notifications[4]. i didn't make any comments or anything it them, just some things hacked together
I think GCM for chrome is somewhat new. It would be cool to add this for a 1.1 release or something. i'm not really sure how much it is used, but the more networks we can unify the better.
-Luke
1. http://developer.chrome.com/apps/cloudMessaging.html
2. https://github.com/lholmquist/aerogear-unified-push-server/tree/chrome
3. https://github.com/lholmquist/aerogear-unified-push-server-admin-ui/tree/...
4. https://github.com/lholmquist/chrome-app-codelab/tree/chromepush/lab2_basic
13 years
Advance Apology
by Kris Borchers
As you may or may not know, the history of the Notifier branch on the aerogear-js repo (https://github.com/aerogear/aerogear-js/tree/Notifier) goes back about 4 months into April. In that time it has been added to, hacked on, forked into a separate branch to release part of Notifier without any of the push bits, kicked in the gut and probably a few other unmentionable things. With that in mind, I wanted to send a preemptive "I'm Sorry" for the history that will merge into master. For the most part it is pretty clean but there are a few places where merge commits of master back into Notifier mess things up a bit. There isn't anything too crazy but being the stickler for clean history I am, this hurts me to do. The only other choice is to endure the pain of going back through and cleaning all of those up and I honestly don't have the energy, nor the time before our release to do it.
With that in mind, please don't git-spank me too hard over this but I will take any hard time you wish to serve up.
13 years
GH Issues vs JIRA
by Kris Borchers
So today I absentmindedly created a GH issue to rename a repo instead of a JIRA. This actually demonstrated a problem we might have. If we don't want to deal with people filing issues on GH and just want JIRAs, we may want to consider turning off issues. I know if I was trying to file a bug and someone asked me to file it again somewhere else, I would be annoyed.
That said, I think we need to be very careful with this. If we turn off GH issues, we would need very prominent links to our contributing guides near the top of every repo's README so people can easily see where they can file issues.
Thoughts?
13 years
Dealing with secured endpoints and CORS
by Sebastien Blanc
Hi Folks,
I'm facing an issue and I hope you could help me on this.
My app is using ag-sec with the @secure annotation and Resteasy.
<https://gist.github.com/sebastienblanc/6133102#scenario-hitting-secured-e...>Scenario:
hitting secured endpoints without CORS (webapp deployed in the same domain)
When the user has not the role specified by @secure I got an exception, as
expected https://gist.github.com/sebastienblanc/6134149
I assume it is because of this
https://github.com/aerogear/aerogear-security/blob/master/src/main/java/o...
and,
perfect, works as designed.
The server returns a nice 401 status to the client.
<https://gist.github.com/sebastienblanc/6133102#testing-in-a-cors-configur...>Testing
in a CORS configuration (web client running under another domain)
Same scenario I'm hitting a secure endpoint without having the role needed
(BTW the OPTIONS preflights are handled without any errors).
I'm getting the same exception from the server but this time no proper 401
answer sent back to the client, and on client side the request is just
canceled.
1. Reproduce it To repoduce this scenario here are the step :
- Clone this branch
https://github.com/sebastienblanc/aerogear-push-quickstart-backend/tree/c...
,mvn clean install , mvn jboss-as:deploy
-
Clone this branch :
https://github.com/aerogear/aerogear-push-quickstart-web/tree/AGPUSH-160 and
deploy it, making sure it's not running on the same port as aerodoc backend
(for instancepython -m SimpleHTTPServer )
-
Browse to the simple client (in case you use python webserver it will be
localhost:8000
-
Login With maria/123
-
Refresh the page : you should see the failure on retrieving the /leads
endpoints.
So, What I'm looking for is to have a normal 401 status sent back to the
client when using CORS, maybe someone has some ides about this ?
Regards,
Seb
13 years
