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@apache.org> wrote:On Thu, Oct 23, 2014 at 1:51 PM, Matthias Wessendorf <matzew@apache.org> wrote:On Wed, Oct 22, 2014 at 6:13 PM, Karel Piwko <kpiwko@redhat.com> 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 herewe 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 URLsIf 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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev