JIRA instances for Push...
by Matthias Wessendorf
Hi,
right now we have three different types of 'push servers':
* UPS
* SimplePush
* WebPush Server
The first two ones each have their own JIRA, but I was wondering if we use
the AGPUSH jira for all three.
To manage releases and bugs, we will go with different/more components, and
for the releases, we could do what we do successfully on our Cordova
project. We can, in JIRA, have releases like:
ups-1.3.0
sps-1.0.0
wps-0.2.0
That way would have all push (server) bits on the same JIRA and
differentiation is simply done using components and versions as discussed
above.
Any thoughts ?
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 4 months
NPE after migrate to 1.1.0.x series
by Bruno Oliveira
Good morning, after banging my head against the wall I decided to ask for help. We started the
tests with Keycloak 1.1.0.Beta1 and Beta2, although after deploying it we get NPE on UPS.
What I identified was that after the commit 94de88ef3b305ad971f81d8610e98a5297f97cd0 the DefaultKeycloakSession
will raise the NPE at:
public <T extends Provider> T getProvider(Class<T> clazz) {
Integer hash = clazz.hashCode();
T provider = (T) providers.get(hash);
if (provider == null) {
ProviderFactory<T> providerFactory = factory.getProviderFactory(clazz);
if (providerFactory != null) {
provider = providerFactory.create(this);
providers.put(hash, provider);
}
}
return provider; //Provider will return null here
}
Maybe is some misconfiguration at https://github.com/keycloak/keycloak/blob/master/project-integrations/aer..., but after dig into KC sources I couldn't find anything weird.
To reproduce the issues with WildFly 8.2.0.final just go to keycloak/project-integrations and run: mvn -Pwildfly clean install wildfly:deploy.
Thanks in advance.
--
abstractj
PGP: 0x84DC9914
10 years, 4 months
better windows push notification support
by Erik Jan de Wit
Hi,
Right now push is supported for windows, but only so called `Toast
Notifications`. I want to add the other message types to the as
described in this gist [1]. Now in the new message format this would
mean to add a couple of fields that are windows specific they should be
ignored by the other push services. So I'm wondering if we should do
that, or if we should put these fields into a sub category called
windows for example:
{
"message":{
"alert":"HELLO!",
"user-data":{
"key":"value"
},
"windows": {
"template" : "cycle",
"title" : "Contoso",
"count" : 10,
"smallBackgroundImage" : "/Assets/Tiles/smallBackgroundImage.jpg",
"cycleImages" :
[
"/Assets/Tiles/cycleImage1.jpg",
"/Assets/Tiles/cycleImage2.jpg",
"/Assets/Tiles/cycleImage3.jpg",
"/Assets/Tiles/cycleImage4.jpg",
"/Assets/Tiles/cycleImage5.jpg",
"/Assets/Tiles/cycleImage6.jpg",
"/Assets/Tiles/cycleImage7.jpg",
"/Assets/Tiles/cycleImage8.jpg",
"/Assets/Tiles/cycleImage9.jpg"
]
}
}
}
What do you think?
[1] https://gist.github.com/edewit/305d76c31960aa6254a9
10 years, 4 months
UP console questions
by Andres Galante
Hey!
I am working on the push console, and I have some questions:
1- What is the main action on the console? What is the main goal a user want to achieve?
I notice that the console is center on creating and seeing up apps and not so much in sending notifications. Is sending notifications usually done on code and not the console?
2- Under each app we have some information mixed with actions:
No variants - Activity - Send Push - admin
What does "admin" do, can an app be manage by other thats not the admin?
3- Once you click on an app name you get a yellow box with "Sending push notifications" set up information. But when you create a variant you also get an specific info box for each variant.
What is the difference between them?
Thanks!
10 years, 4 months
