Hi All, I'd like to know your opinion on following changes to UnifiedPush Server. They are both focused on improving customization process for the cartridge. Just in short, current update process now: 1/ Clone official git repository of cartridge 2/ Extract wars and do the modifications or build ones 3/ Package wars 4/ Push cartridge to your own repository 5/ Create cartridge from your own repository Whereas, I'm proposing: 1/ Create cartridge from official repository 2/ Clone git repository for gear created by Openshift (by default if rhc is used) 3/ Modify some files there we expose for user modification 4/ Push back to make changes live What particular configuration elements I'm interested to have externalized? 1/ Ability to load keycloak.json from external location => This allows user to create cartridge and modify it prior the first access. This allows users to configure it to be consumable by other services automatically, e.g. they can add developer users, roles, etc.

2/ Externalize GCM/APNs locations => Now, URLs are hardcoded in GCM/APNs JARs.

If they would be loaded from external location (defaults can still be hardcoded), this allows user to easily check business logic that queries data in UPS and not sending any messages. Also allows to put proxy in between UPS and APNs/GCMs. Both these will significantly reduce QE overhead. However, I believe they are valuable for other as well. Feedback and tomatoes (I prefer plum ones) are welcomed. Thanks, Karel _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Oct 23, 2014 at 1:51 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Wed, Oct 22, 2014 at 6:13 PM, Karel Piwko <kpiwko(a)redhat.com&gt; wrote: > >> Hi All, >> >> I'd like to know your opinion on following changes to UnifiedPush >> Server. They are both focused on improving customization process for the >> cartridge. >> >> Just in short, current update process now: >> 1/ Clone official git repository of cartridge >> 2/ Extract wars and do the modifications or build ones >> 3/ Package wars >> 4/ Push cartridge to your own repository >> 5/ Create cartridge from your own repository >> >> Whereas, I'm proposing: >> 1/ Create cartridge from official repository >> 2/ Clone git repository for gear created by Openshift (by default if rhc >> is used) >> 3/ Modify some files there we expose for user modification >> 4/ Push back to make changes live >> >> What particular configuration elements I'm interested to have >> externalized? >> >> 1/ Ability to load keycloak.json from external location >> >> => This allows user to create cartridge and modify it prior the first >> access. This allows users to configure it to be consumable by other >> services automatically, e.g. they can add developer users, roles, etc. >> > > hrm, in theory, yeah, that could be possible. Perhaps Stian or abstractj > have an idea here > we could have our real in a JSON file, so that it is easy/easier to import it into an existing KC server, to run UPS against that > > > >> >> 2/ Externalize GCM/APNs locations >> >> => Now, URLs are hardcoded in GCM/APNs JARs. > > > yes, they are considered stable APIs :) > > We are not going to 'externalize' these URLs > > >> If they would be loaded >> from external location (defaults can still be hardcoded), this allows >> user to easily check business logic that queries data in UPS and not >> sending any messages. Also allows to put proxy in between UPS and >> APNs/GCMs. >> >> Both these will significantly reduce QE overhead. However, I believe >> they are valuable for other as well. >> >> Feedback and tomatoes (I prefer plum ones) are welcomed. >> >> Thanks, >> >> Karel >> >> _______________________________________________ >> 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

yes, our cartridge will still function like that I think what we can do for Karel, is have the realm.json file, for UPS so he and team can import it into running keycloak. Our cartridge will stay as is, at least that's my (current) understanding On Thu, Oct 23, 2014 at 4:07 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > If we go for this let's make sure we have default values. > A lot of people might create an OpenShift App just using the online > interface and not clone it locally (and thus not modify the config files) > > > On Thu, Oct 23, 2014 at 2:06 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > >> >> >> On Thu, Oct 23, 2014 at 1:51 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >>> >>> >>> On Wed, Oct 22, 2014 at 6:13 PM, Karel Piwko <kpiwko(a)redhat.com&gt; wrote: >>> >>>> Hi All, >>>> >>>> I'd like to know your opinion on following changes to UnifiedPush >>>> Server. They are both focused on improving customization process for the >>>> cartridge. >>>> >>>> Just in short, current update process now: >>>> 1/ Clone official git repository of cartridge >>>> 2/ Extract wars and do the modifications or build ones >>>> 3/ Package wars >>>> 4/ Push cartridge to your own repository >>>> 5/ Create cartridge from your own repository >>>> >>>> Whereas, I'm proposing: >>>> 1/ Create cartridge from official repository >>>> 2/ Clone git repository for gear created by Openshift (by default if rhc >>>> is used) >>>> 3/ Modify some files there we expose for user modification >>>> 4/ Push back to make changes live >>>> >>>> What particular configuration elements I'm interested to have >>>> externalized? >>>> >>>> 1/ Ability to load keycloak.json from external location >>>> >>>> => This allows user to create cartridge and modify it prior the first >>>> access. This allows users to configure it to be consumable by other >>>> services automatically, e.g. they can add developer users, roles, etc. >>>> >>> >>> hrm, in theory, yeah, that could be possible. Perhaps Stian or abstractj >>> have an idea here >>> >> >> we could have our real in a JSON file, so that it is easy/easier to >> import it into an existing KC server, to run UPS against that >> >> >>> >>> >>> >>>> >>>> 2/ Externalize GCM/APNs locations >>>> >>>> => Now, URLs are hardcoded in GCM/APNs JARs. >>> >>> >>> yes, they are considered stable APIs :) >>> >>> We are not going to 'externalize' these URLs >>> >>> >>>> If they would be loaded >>>> from external location (defaults can still be hardcoded), this allows >>>> user to easily check business logic that queries data in UPS and not >>>> sending any messages. Also allows to put proxy in between UPS and >>>> APNs/GCMs. >>>> >>>> Both these will significantly reduce QE overhead. However, I believe >>>> they are valuable for other as well. >>>> >>>> Feedback and tomatoes (I prefer plum ones) are welcomed. >>>> >>>> Thanks, >>>> >>>> Karel >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Oct 22, 2014 at 6:13 PM, Karel Piwko <kpiwko(a)redhat.com&gt; wrote: > Hi All, > > I'd like to know your opinion on following changes to UnifiedPush > Server. They are both focused on improving customization process for the > cartridge. > > Just in short, current update process now: > 1/ Clone official git repository of cartridge > 2/ Extract wars and do the modifications or build ones > 3/ Package wars > 4/ Push cartridge to your own repository > 5/ Create cartridge from your own repository > > Whereas, I'm proposing: > 1/ Create cartridge from official repository > 2/ Clone git repository for gear created by Openshift (by default if rhc > is used) > 3/ Modify some files there we expose for user modification > 4/ Push back to make changes live > > What particular configuration elements I'm interested to have > externalized? > > 1/ Ability to load keycloak.json from external location > > => This allows user to create cartridge and modify it prior the first > access. This allows users to configure it to be consumable by other > services automatically, e.g. they can add developer users, roles, etc. > hrm, in theory, yeah, that could be possible. Perhaps Stian or abstractj have an idea here

> > 2/ Externalize GCM/APNs locations > > => Now, URLs are hardcoded in GCM/APNs JARs. yes, they are considered stable APIs :) We are not going to 'externalize' these URLs > If they would be loaded > from external location (defaults can still be hardcoded), this allows > user to easily check business logic that queries data in UPS and not > sending any messages. Also allows to put proxy in between UPS and > APNs/GCMs. > > Both these will significantly reduce QE overhead. However, I believe > they are valuable for other as well. > > Feedback and tomatoes (I prefer plum ones) are welcomed. > > Thanks, > > Karel > > _______________________________________________ > 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